Re: [PATCH] PR 62173, re-shuffle insns for RTL loop invariant hoisting

[Jeff Law <law at redhat dot com>]

On 05/14/2015 03:13 PM, Jiong Wang wrote:
> Jeff Law writes:
>
> > For all kinds of reassociation we have to concern ourselves with adding
> > overflow where it didn't already occur.  Assuming a 32 bit architecture
> > we could get overflow if A is 0x7fffffff, b is -4 and and c = 3
> >
> > 0x7fffffff + -4 = 0x7ffffffb
> > 0x7ffffffb + 3 = 0x7ffffffe
> >
> >
> > If you make the transformation you're suggesting we get
> >
> > 0x7fffffff + 3 = 0x80000002  OVERFLOW
> > 0x80000002 - 4 = 0x7ffffffe
> >
> > Now if you always know pointers are unsigned, then the overflow is
> > defined and you'd be OK.  But that's a property of the target and one
> > that's not well modeled within GCC (we have POINTER_EXTEND_UNSIGNED
> > which kind of tells us something in this space).
>
> I see, understood, cool! Thanks for such detailed explanation.
>
> Above scenario do may happen for general pointer arith
> reassociation.
>
> One thing may make life easier as my reassociation is restricted within
> frame pointer. the "(plus (plus fp, index_reg) + const_off)" pattern was
> to address some variable on stack. index_reg, const_off were part of
> the stack offset of the variable. Reassociate them means reorder two
> parts of the stack offset. There may be way to prove the transformation
> will not add extra overflow risk, especially when the index_reg is
> unsigned.
>
> I understand for general pointer arith reassociation, there do have big
> risk, as the involved operands largely come from irrelevant instruction,
> no relationship between the values from those operands, we can deduce nothing.
Given the special status of SP, FP and ARGP and a known constant part, 
we can probably do something here.  More below...



> > In addition to worrying about overflow, you have to worry about
> > segmented architectures with implicit segment selection -- especially if
> > the segment selection comes from the base register than the entire
> > effective address.
>
> Hmm, understood!
>
> This let me recall something as dark as x86 segment descriptor in protecting mode...
Possibly, I've actually never studied the segmented aspects of the x86. 
 But I'm painfully familiar with the others mentioned :(

My recollection for the segmented stuff on the PA is we only had a 
single guard page at both ends of the segment.  So we only allowed an 
offset of +-4k when doing address reassociations in legitimize_address. 
 This was possible because we had callouts from the right places in the 
RTL generators/optimizers to allow targets to rewrite address 
arithmetic.  So we could naturally bury the target details away from the 
code generator/optimizers.

So we could possibly parameterize the transformation around similar 
concepts.  The design issue here is it's introducing more target 
dependencies in places where we've really wanted to avoid them.  In 
theory the gimple optimizers are supposed to be target independent. 
Reality is some stuff bleeds into them (the one that's mentioned the 
most often is branch costing, but there's others).

*If* we decide to go forward with using some target hooks here.  I'd be 
tempted to do 2.  One that's effective a tri-state.  Full reassociation, 
limited reassociation, no reassociation.  The second would bound the 
constants in the limited reassociation case.

Thoughts?

Jeff