https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26190

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Jim Wilson from comment #3)
> This ior/shift/xor optimization be done during combine with a simplify-rtx.c
> patch.  I wrote a prototype and tested it.  Combine canonicalizes
> shift/logical as logical/shift, so we actually have to look for
> ior/xor/shift.  I see that the optimization does not happen on arm and
> aarch64 because the 0x4002 value does not fit into the immediate range for
> logical ops, gets loaded into a register, pulled out of the loop, and hence
> is not available to combine.  We would have to perform the optimization
> earlier for it to work for arm/aarch64.  I tried MIPS, and see that because
> MIPS promotes HImode to SImode we don't have enough info to prove that the
> opt is safe.  We need type info to make this work.  This prototype does work
> for the x86 target which has both 16-bit immediates and HImode instructions.
> 
> Next I wrote a prototype for match-and-simplify.  This one works for all 4
> targets.  We have to handle ior/shift/xor as match-and-simplify does not
> canonicalize logical/shift.  I noticed that if I change the xor to an ior,
> then it gets optimized in combine because of the canonicalization for mips
> and x86, but not for arm/aarch64 again because the constant was pulled out
> of the loop.  So it seems that match-and-simplify should canonicalize
> shift/logical to logical/shift too.  That would also reduce the number of
> patterns we need to match when performing this ior/shift/xor optimization.
> 
> These are prototype patches that need a bit more work to handle more cases,
> and to prove that they test all conditions necessary to make them safe. 
> This is my first attempt to use the wi:: functions, so there might be a
> better way to do this.

Have you made further attempts since?

Reply via email to