On 10/10/2014 09:52 AM, Richard Henderson wrote:
> I wonder what kind of fallout there would be from changing LO_SUM to
> RTX_BIN_ARITH, which is what it should have been all along.
The answer is "a lot". Mostly throughout simplify-rtx.c, wherein we'd have to
move all sorts of code around to acco
On 10/10/14 11:25, Richard Henderson wrote:
On 10/10/2014 10:21 AM, Jeff Law wrote:
On 10/10/14 11:04, Jakub Jelinek wrote:
On Fri, Oct 10, 2014 at 11:00:54AM -0600, Jeff Law wrote:
But it's really a lot more like a
kind of PLUS. If instead we had a LOW to match HIGH it would have been
R
On 10/10/2014 10:21 AM, Jeff Law wrote:
> On 10/10/14 11:04, Jakub Jelinek wrote:
>> On Fri, Oct 10, 2014 at 11:00:54AM -0600, Jeff Law wrote:
>>> But it's really a lot more like a
kind of PLUS. If instead we had a LOW to match HIGH it would have been
>>> Right. In fact, I believe at the h
On 10/10/14 11:04, Jakub Jelinek wrote:
On Fri, Oct 10, 2014 at 11:00:54AM -0600, Jeff Law wrote:
But it's really a lot more like a
kind of PLUS. If instead we had a LOW to match HIGH it would have been
Right. In fact, I believe at the hardware level it's typically implemented
as addition.
On Fri, Oct 10, 2014 at 11:00:54AM -0600, Jeff Law wrote:
> But it's really a lot more like a
> >kind of PLUS. If instead we had a LOW to match HIGH it would have been
> Right. In fact, I believe at the hardware level it's typically implemented
> as addition.
Can be addition or bitwise or, as h
On 10/10/14 10:52, Richard Henderson wrote:
I missed that message. Interesting.
I wonder what kind of fallout there would be from changing LO_SUM to
RTX_BIN_ARITH, which is what it should have been all along.
My guess is that someone looked at HIGH being RTX_CONST_OBJ and thought that
LO_SUM
On 10/10/2014 09:39 AM, Jiong Wang wrote:
>> (1) Don't bother modifying single_set; just look for a bare SET.
>> (2) Tighten the set of expressions we're willing to move.
>> (3) Use direct "return false" in the failure case, rather than
>> counting a non-zero number of non-constants, etc.
>>
>
On 10/10/14 16:59, Richard Henderson wrote:
On 10/08/2014 08:31 AM, Jiong Wang wrote:
Ping ~
And as there is NONDEBUG_INSN_P check before move_insn_for_shrink_wrap invoked,
we could avoid creating new wrapper function by invoke single_set_2 directly.
I'm committing the following to fix this.
On 10/08/2014 08:31 AM, Jiong Wang wrote:
>
> On 30/09/14 19:36, Jiong Wang wrote:
>> 2014-09-30 17:30 GMT+01:00 Jeff Law :
>>> On 09/30/14 08:37, Jiong Wang wrote:
On 30/09/14 05:21, Jeff Law wrote:
> I do agree with Richard that it would be useful to see the insns that
> a
On 30/09/14 19:36, Jiong Wang wrote:
2014-09-30 17:30 GMT+01:00 Jeff Law :
On 09/30/14 08:37, Jiong Wang wrote:
On 30/09/14 05:21, Jeff Law wrote:
I do agree with Richard that it would be useful to see the insns that
are incorrectly sunk and the surrounding context.
So I must be missing so
On Tue, Sep 30, 2014 at 6:51 PM, Richard Earnshaw wrote:
> It's not just clobbers; it ignores patterns like
>
> (parallel
> [(set (a) (...)
> (set (b) (...)])
> [(reg_note (reg_unused(b))]
>
> Which is probably fine before register allocation but definitely
> something you have to think about af
2014-09-30 17:30 GMT+01:00 Jeff Law :
> On 09/30/14 08:37, Jiong Wang wrote:
>>
>>
>> On 30/09/14 05:21, Jeff Law wrote:
>>>
>>> On 09/29/14 13:24, Jiong Wang wrote:
I don't think so. from the x86-64 bootstrap, there is no regression
on the number of functions shrink-wrapped. actuall
On 30/09/14 17:45, Jeff Law wrote:
> On 09/30/14 08:15, Richard Earnshaw wrote:
>>
>> I think part of the problem is in the naming of single_set(). From the
>> name it's not entirely obvious to users that this includes insns that
>> clobber registers or which write other registers that are unused
On 09/30/14 08:15, Richard Earnshaw wrote:
I think part of the problem is in the naming of single_set(). From the
name it's not entirely obvious to users that this includes insns that
clobber registers or which write other registers that are unused after
that point. I've previously had to fix
On 09/30/14 08:37, Jiong Wang wrote:
On 30/09/14 05:21, Jeff Law wrote:
On 09/29/14 13:24, Jiong Wang wrote:
I don't think so. from the x86-64 bootstrap, there is no regression
on the number of functions shrink-wrapped. actually speaking,
previously only single mov dest, src handled, so the di
On 30/09/14 05:21, Jeff Law wrote:
On 09/29/14 13:24, Jiong Wang wrote:
I don't think so. from the x86-64 bootstrap, there is no regression
on the number of functions shrink-wrapped. actually speaking,
previously only single mov dest, src handled, so the disallowing
USE/CLOBBER will not disallo
On 29/09/14 19:32, Richard Henderson wrote:
> On 09/29/2014 11:12 AM, Jiong Wang wrote:
>> +inline rtx single_set_no_clobber_use (const rtx_insn *insn)
>> +{
>> + if (!INSN_P (insn))
>> +return NULL_RTX;
>> +
>> + if (GET_CODE (PATTERN (insn)) == SET)
>> +return PATTERN (insn);
>> +
>> +
On 09/29/14 13:24, Jiong Wang wrote:
I don't think so. from the x86-64 bootstrap, there is no regression
on the number of functions shrink-wrapped. actually speaking,
previously only single mov dest, src handled, so the disallowing
USE/CLOBBER will not disallow shrink-wrap opportunity which was
On Mon, 2014-09-29 at 20:24 +0100, Jiong Wang wrote:
> On 29/09/14 19:32, Richard Henderson wrote:
> > On 09/29/2014 11:12 AM, Jiong Wang wrote:
> >> +inline rtx single_set_no_clobber_use (const rtx_insn *insn)
> >> +{
> >> + if (!INSN_P (insn))
> >> +return NULL_RTX;
> >> +
> >> + if (GET_CO
On 29/09/14 19:32, Richard Henderson wrote:
On 09/29/2014 11:12 AM, Jiong Wang wrote:
+inline rtx single_set_no_clobber_use (const rtx_insn *insn)
+{
+ if (!INSN_P (insn))
+return NULL_RTX;
+
+ if (GET_CODE (PATTERN (insn)) == SET)
+return PATTERN (insn);
+
+ /* Defer to the more exp
On 09/29/2014 11:12 AM, Jiong Wang wrote:
> +inline rtx single_set_no_clobber_use (const rtx_insn *insn)
> +{
> + if (!INSN_P (insn))
> +return NULL_RTX;
> +
> + if (GET_CODE (PATTERN (insn)) == SET)
> +return PATTERN (insn);
> +
> + /* Defer to the more expensive case, and return NULL_R
21 matches
Mail list logo
