This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH: PR/40314] extract common address for memory access to fields of large struct


Carrot Wei writes:
> Thank you, Adam. Your method can solve part of the problems just as
> you described.

Thanks for confirming.

> But my pass can expose more opportunities to CSE and GCSE:
> 
> 1. Due to lack of target specific information, CSE may do wrong
> optimization. Suppose we have two byte memory accesses with address
> (base+400) and (base+440), CSE may transform them to
>      t1 = base + 400
>      // t1 is used as address 1
>      ...
>      t2 = t1 + 40
>      // t2 is used as address 2 to load a byte
> 
>    Actually in thumb mode byte loading can only have offset range of
> [0, 31]. This transform does not help.

You should be able to describe this in TARGET_RTX_COSTS hook in your backend.

> 2. In other cases CSE may miss some optimization because it can only
> use the available value. One simple example is:
> 
>    t1 = base + 404
>    // t1 is used as address 1
>    ...
>    t2 = base + 400
>    // t2 is used as address 2
> 
>   Address2 is 4 bytes smaller than address1, and used later than
> address1. In thumb mode memory offset can't be negative. Current CSE
> framework can't deal with this situation.

Yes this case would be missed.  These CSE optimizations are most effective if
there are instructions to get from one expression to the other regardless of
the order, i.e. when the offsetting is symmetric.

I still think however that it would be better to have a new local pass
complementing rather than duplicating the related-value optimizations in CSE.
The pass could rearrange the order of additive expression to maximize reuse
and would be limited to targets that have this asymmetry.

> 3. CSE works on superblock only. I hope this optimization can also be
> done globally.

This has been discussed a few times already
(e.g. <http://gcc.gnu.org/ml/gcc/2009-03/msg00475.html>).

Adam


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]