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
Thank you Segher, I will send an updated patch for stage 1.
regards,
Venkat.
On 22 January 2015 at 21:46, Segher Boessenkool
wrote:
> On Thu, Jan 22, 2015 at 07:29:28PM +0530, Venkataramanan Kumar wrote:
>> ping. Segher do you any comments from your side.
>
> I agree combine should not transfor
On Thu, Jan 22, 2015 at 07:29:28PM +0530, Venkataramanan Kumar wrote:
> ping. Segher do you any comments from your side.
I agree combine should not transform shifts into multiplication (except
in addresses, where it is canonical). I haven't looked at the actual
patch in detail though, it will hav
ping. Segher do you any comments from your side.
regards,
Venkat.
On 14 January 2015 at 16:57, 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.
>
> T
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
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 for scalar int modes and tries to optimize based o
10 matches
Mail list logo
