"Simple" delay chain mystery

--- Quote Start ---

If an intermediate result is brought out of the chip, it cannot be optimized out by the compiler...and preserving that intermediate step must produce a delay, which is what I wanted.

--- Quote End ---

Well, of course the intermediate result can't be ignored in this case, but this is sure only for the expression brought to the pin. But it isn't necessarily used for another expression, that may use the intermediate result. The compiler will most likely ignore it, if it could represent it directly with the same LUT count. Apart from my assumptions, also the empirical results apparently shows, that there is no must for the intermediate step.

P.S.: Here is a simple example, how a delay chain can be defined in Quartus. I didn't check in hardware, but according to Technology Map Viewer and Timing Simulator, it operates as such. However, I don't want to suggest this technique for real designs.

library ieee;
use ieee.std_logic_1164.all;
entity chain is
  port 
  (
    inp : in  std_logic;
    outp: out std_logic
  );
end entity;
architecture rtl of chain is
signal wire1: std_logic;
signal wire2: std_logic;
signal wire3: std_logic;
signal wire4: std_logic;
attribute syn_keep: boolean;
attribute syn_keep of wire1: signal is true;
attribute syn_keep of wire2: signal is true;
attribute syn_keep of wire3: signal is true;
attribute syn_keep of wire4: signal is true;
begin
  wire1 <= inp;
  wire2 <= wire1;
  wire3 <= wire2;
  wire4 <= wire3;
  outp <= wire4 xor inp;
end;