On Wed, Mar 7, 2012 at 6:40 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
Richard Kenner wrote:
Given the current set of results, since I do not have any way to verify
whether my simplify_set changes would actually trigger correctly, I'd
rather propose to just remove the SUBREG case in
Richard Kenner wrote:
Given the current set of results, since I do not have any way to verify
whether my simplify_set changes would actually trigger correctly, I'd
rather propose to just remove the SUBREG case in apply_distributive_law
(i.e. only apply the first patch below).
Richard Kenner wrote:
Maybe the best solution would be to remove the SUBREG case from the generic
apply_distributive_law subroutine, and instead add a special check for the
distributed subreg case right at the above place in simplify_set; i.e. to
perform the inverse distribution only if it
I tried to implement that suggestion, but interestingly enough I cannot
really test it since I was unable to find any single case where that
SUBREG case in apply_distributive_law actually causes any difference
whatsoever in generated code.
Do you have any further suggestion of how to find a
Richard Kenner wrote:
The problem appears to be that an RTX expression like
(minus:QI (subreg:QI (reg:SI 64 [ a ]) 0)
(subreg:QI (reg:SI 66 [ b ]) 0))
seems to be considered non-canonical by combine, and is instead
transformed into
(subreg:QI
Maybe the best solution would be to remove the SUBREG case from the generic
apply_distributive_law subroutine, and instead add a special check for the
distributed subreg case right at the above place in simplify_set; i.e. to
perform the inverse distribution only if it is already guaranteed
[Richard, combine question at the bottom for you. I've quoted Ulrich's
whole message in order to provide a bit of context.]
Ulrich Weigand uweig...@de.ibm.com writes:
Richard Sandiford wrote:
At the moment, fwprop will propagate constants and registers
even if no further rtl simplifications
[Richard, combine question at the bottom for you. I've quoted Ulrich's
whole message in order to provide a bit of context.]
I don't remember ALL of this, but can perhaps make a few hints.
The problem appears to be that an RTX expression like
(minus:QI (subreg:QI (reg:SI 64 [ a ])
Richard Sandiford wrote:
At the moment, fwprop will propagate constants and registers
even if no further rtl simplifications are possible:
if (REG_P (new_rtx) || CONSTANT_P (new_rtx))
flags |= PR_CAN_APPEAR;
What do you think about extending this to subregs?
I've been testing your
On 01/11/2012 05:55 PM, Ulrich Weigand wrote:
In either case, it is always odd to have RTX in the insn stream
that isn't stable under common simplication ... Do you have
any suggestions on how to fix this? If we add the fwprop patch,
should we then disable apply_distributive_law for SUBREGs?
At the moment, fwprop will propagate constants and registers
even if no further rtl simplifications are possible:
if (REG_P (new_rtx) || CONSTANT_P (new_rtx))
flags |= PR_CAN_APPEAR;
What do you think about extending this to subregs? The reason for
asking is that on NEON, vector loads
On Wed, Sep 14, 2011 at 8:24 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
At the moment, fwprop will propagate constants and registers
even if no further rtl simplifications are possible:
if (REG_P (new_rtx) || CONSTANT_P (new_rtx))
flags |= PR_CAN_APPEAR;
What do you think
H.J. Lu hjl.to...@gmail.com writes:
On Wed, Sep 14, 2011 at 8:24 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
At the moment, fwprop will propagate constants and registers
even if no further rtl simplifications are possible:
if (REG_P (new_rtx) || CONSTANT_P (new_rtx))
flags
On 09/14/2011 05:44 PM, Richard Sandiford wrote:
A SUBREG may not be REG nor CONSTANT. Don't you need
to check REG_P/CONSTANT_P on SUBREG?
Yeah, good point. There should be a REG_P (SUBREG_REG (new_rtx))
in there. Probably also worth checking for non-paradoxical subregs.
I was going
14 matches
Mail list logo
