On Wed, May 06, 2015 at 08:32:13AM +0100, Richard Sandiford wrote:
> > Alternately, you could find a way to accurately track if we're inside a
> > MEM, where we want to canonicalize things slightly differently. Once we
> > can accurately track if we're inside a MEM, then we no longer have to
>
Jeff Law writes:
> On 01/16/2015 12:13 AM, Venkataramanan Kumar wrote:
>>
>> The below test case which I am working on is from the PR63949
>>
>> int subsi_sxth (int a, short i)
>> {
>>/* { dg-final { scan-assembler "sub\tw\[0-9\]+,.*sxth #?1" } } */
>>return a - ((int)i << 1);
>> }
>>
>
On 01/16/2015 12:13 AM, Venkataramanan Kumar wrote:
The below test case which I am working on is from the PR63949
int subsi_sxth (int a, short i)
{
/* { dg-final { scan-assembler "sub\tw\[0-9\]+,.*sxth #?1" } } */
return a - ((int)i << 1);
}
The expression "a - ((int)i << 1)" is not a
Hi jeff and Richard
On 15 January 2015 at 03:10, Jeff Law wrote:
> On 01/14/15 04:27, Venkataramanan Kumar wrote:
>>
>> Hi all,
>>
>> When trying to debug GCC combiner pass with the test case in PR63949
>> ref https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63949 I came across this
>> code.
>>
>> Th
On 01/14/2015 03:27 AM, Venkataramanan Kumar wrote:
>next_code = (code == MEM ? MEM
>: ((code == PLUS || code == MINUS)
> - && SCALAR_INT_MODE_P (mode)) ? MEM
> + && SCALAR_INT_MODE_P (mode)
> + && (in_code == MEM)) ? MEM
>
On 01/14/15 04:27, Venkataramanan Kumar wrote:
Hi all,
When trying to debug GCC combiner pass with the test case in PR63949
ref https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63949 I came across this code.
This code in "make_compound_operation" assumes that all PLUS and MINUS
RTX are "MEM" type f
