Optimise CONCAT handling in emit_group_load
authorRichard Sandiford <richard.sandiford@arm.com>
Wed, 16 Nov 2016 10:21:22 +0000 (10:21 +0000)
committerRichard Sandiford <rsandifo@gcc.gnu.org>
Wed, 16 Nov 2016 10:21:22 +0000 (10:21 +0000)
commit024f701ca1dc69ff3d6a3d0ec727debc224018f0
tree52508ae9bd9955501846133b59b4d7f9e41e762a
parent0e0af68921530695ddfd86780a0d955674ef239f
Optimise CONCAT handling in emit_group_load

The CONCAT handling in emit_group_load chooses between doing
an extraction from a single component or forcing the whole
thing to memory and extracting from there.  The condition for
the former (more efficient) option was:

  if ((bytepos == 0 && bytelen == slen0)
      || (bytepos != 0 && bytepos + bytelen <= slen))

On the one hand this seems dangerous, since the second line
allows bit ranges that start in the first component and leak
into the second.  On the other hand it seems strange to allow
references that start after the first byte of the second
component but not those that start after the first byte
of the first component.  This led to a pessimisation of
things like gcc.dg/builtins-54.c for hppa64-hp-hpux11.23.

This patch simply checks whether the reference is contained
within a single component.  It also makes sure that we do
an extraction on anything that doesn't span the whole
component (even if it's constant).

gcc/
2016-11-15  Richard Sandiford  <richard.sandiford@arm.com>
    Alan Hayward  <alan.hayward@arm.com>
    David Sherwood  <david.sherwood@arm.com>

* expr.c (emit_group_load_1): Tighten check for whether an
access involves only one operand of a CONCAT.  Use extract_bit_field
for constants if the bit range does span the whole operand.

Co-Authored-By: Alan Hayward <alan.hayward@arm.com>
Co-Authored-By: David Sherwood <david.sherwood@arm.com>
From-SVN: r242477
gcc/ChangeLog
gcc/expr.c