On 05/18/2012 09:16 AM, H.J. Lu wrote:
> On Thu, May 17, 2012 at 1:46 PM, Meador Inge wrote:
>> On 05/17/2012 03:02 PM, Richard Sandiford wrote:
>>
>>> After agonising over this for a couple of days, I think it's probably
>>> the correct fix. What we're doing now would be valid if the only use o
On 05/18/2012 09:16 AM, H.J. Lu wrote:
> On Thu, May 17, 2012 at 1:46 PM, Meador Inge wrote:
>> On 05/17/2012 03:02 PM, Richard Sandiford wrote:
>>
>>> After agonising over this for a couple of days, I think it's probably
>>> the correct fix. What we're doing now would be valid if the only use o
On Thu, May 17, 2012 at 1:46 PM, Meador Inge wrote:
> On 05/17/2012 03:02 PM, Richard Sandiford wrote:
>
>> After agonising over this for a couple of days, I think it's probably
>> the correct fix. What we're doing now would be valid if the only use of
>> equiv_constant(x) were to substitute for
Meador Inge writes:
> v2 OK? If so, would you mind committing for me? I don't have write access.
Applied, thanks. (BTW, I removed the brackets around the new condition.)
Richard
On 05/17/2012 03:02 PM, Richard Sandiford wrote:
> After agonising over this for a couple of days, I think it's probably
> the correct fix. What we're doing now would be valid if the only use of
> equiv_constant(x) were to substitute for x. The name and current use
> of the function obviously re
Steven Bosscher writes:
> On Thu, May 17, 2012, Meador Inge wrote:
>>> ;; This is *not* equal to zero because the upper
>>> ;; two bytes are undefined.
>>> (insn 14 13 15 2 (set (reg:SI 142)
>>> (subreg:SI (reg:QI 141) 0))
>>> (expr_list:REG_EQUAL (const_int 0 [0])
>>> (nil))
On Thu, May 17, 2012, Meador Inge wrote:
>> ;; This is *not* equal to zero because the upper
>> ;; two bytes are undefined.
>> (insn 14 13 15 2 (set (reg:SI 142)
>> (subreg:SI (reg:QI 141) 0))
>> (expr_list:REG_EQUAL (const_int 0 [0])
>> (nil)))
Hmm, this is what doc/rtl.texi
I meant to CC the RTL optimization maintainers before ...
On 05/15/2012 02:39 PM, Meador Inge wrote:
> Hi All,
>
> As reported in PR rtl-optimization/53352 CSE currently trips up on a
> paradoxical subreg case. When compiling for ARM GNU/Linux with -O3
> the expanded RTL of interest looks like:
Hi All,
As reported in PR rtl-optimization/53352 CSE currently trips up on a
paradoxical subreg case. When compiling for ARM GNU/Linux with -O3
the expanded RTL of interest looks like:
(insn 12 11 13 3 (set (reg:SI 140)
(lshiftrt:SI (reg/v:SI 135 [ tmp1 ])
(const_int 16 [0x10
