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

[Jiong Wang]

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.

>
> 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...

>
> Sadly we don't expose this aspect of target characteristics at all.
>
>
> To proceed, you'd probably need ways to conditionalize these 
> transformations.  ie, target hooks.
>
> Jeff

-- 
Regards,
Jiong