PR 18294: help with rtl-optimization bug on IA64

[James E Wilson]

Steve Ellcey wrote:
> I was wondering if anyone could offer some advice on PR 18294.  It
> breaks the IA64 HP-UX bootstrap and I cut the problem down to a
> small test case (see the defect report) and then tracked the problem
> down to the code that is inside the POINTERS_EXTEND_UNSIGNED ifdef in
> instantiate_virtual_regs_1 (function.c).

Put a breakpoint in make_insn_raw, make it conditional on the 
instruction number (91 in your case), then look at the call stack, and 
we see that the problem is the gen_lowpart call.  This may create new 
RTL, and does in this case.  New RTL is put at the current insertion 
point, which normally is the end of the function.  This can be changed 
by emitting the RTL into a sequence, but there is no sequence here to 
hold the RTL.

There is also a related problem, if the validate_change call fails, then 
we have to delete the new RTL created by gen_lowpart, but there is no 
code for this.  Again, this can be fixed by using a sequence.

New RTL is created in this case because simplify_subreg refuses to 
create a subreg of the frame pointer.  The comments say return without 
doing anything, to leave the subreg as a subreg.  However, we are 
calling simplify_subreg from simplify_gen_subreg, and 
simplify_gen_subreg returns NULL if the input was a hard register.  This 
seems to be a bug in simplify_gen_subreg.  If we have a special reg like 
ap/sp/fp, then it should go ahead and create the subreg, which is the 
intent here.  The test in simplify_gen_subreg needs to be based on the 
test in simplify_subreg, to ensure that we only create the subregs when 
simplify_subreg wanted us to.  I.e. we create them for the special regs 
ap/sp/fp, but not when the CANNOT_CHANGE_MODE_CLASS says we can't create 
the subreg.  There might be a better way to structure this.  If this 
problem is fixed, then gen_lowpart probably won't ever generate new RTL 
in this case anymore, and we may not have to worry about creating and 
using sequences here.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com