Re: Question about how to fix PR69052

["Bin.Cheng" <amker dot cheng at gmail dot com>]

On Tue, Jan 26, 2016 at 4:26 PM, Jeff Law <law@redhat.com> wrote:
> On 01/26/2016 02:28 AM, Bin.Cheng wrote:
>>
>> Yes, loop invariant now increased invariant cost if the invariant
>> can't be propagated into address expression.  Problem is we check
>> propagation by simply replacing use with def in memory reference then
>> verifying result insn with verify_changes.  Apparently more advanced
>> transforms are necessary, just like what combine does.
>> I am surprised that rtl_fwprop_addr doesn't handle this either, it's
>> an exact address expression propagation example.
>
> So the question now becomes whether or not the work done by combine.c is
> dependent on knowledge that is specific to combine or is it just a series of
> transformations that we could make available (preferably moving it to
> simplify-rtx).
>
> If we can factor the transformation out and shove it into simplify-rtx, then
> it could be used elsewhere.
According to comment at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052#c6, it should be
just re-arrangement of operands, if the comment itself holds.
In this way, the transformation is backend related, maybe better to
keep it in backend, right?

Thanks,
bin
>
> jeff