Hi,
Consider code:
int foo(char *t, char *v, int w)
{
int i;
for (i = 1; i != w; ++i)
{
int x = i << 2;
v[x + 4] = t[x + 4];
}
return 0;
}
Compile it to x86 (I used both gcc 4.7.2 and gcc 4.8.1) with options:
gcc -O2 -m32 -S test.c
You will see loop, formed like:
.L5:
leal 0(,%eax,4), %edx
Hum, I can't change gcc branch because I'm tighted to gnat 7.1.2 based on gcc
4.7.3 (I saw that LRA was merged in 4.8). I will use a workaround for the
moment (i.e. disable wide offset MEM on conditional moves).
Does someone know if gnat frontend will rebase on 4.8 soon :) ? (or maybe LRA
will b
Eric Botcazou writes:
>> Well, I think making the simplify-rtx code conditional on the target
>> would be the wrong way to go. If we really can't live with it being
>> unconditional then I think we should revert it. But like I say I think
>> it would be better to make combine recognise the redun
On 06-Dec-13 01:34 AM, Maxim Kuvyrkov wrote:
On 6/12/2013, at 8:44 am, shmeel gutl wrote:
On 05-Dec-13 02:39 AM, Maxim Kuvyrkov wrote:
Dependency type plays a role for estimating costs and latencies between
instructions (which affects performance), but using wrong or imprecise
dependency ty
On Fri, Dec 6, 2013 at 12:41 AM, BELBACHIR Selim
wrote:
> Hum, I can't change gcc branch because I'm tighted to gnat 7.1.2 based on gcc
> 4.7.3 (I saw that LRA was merged in 4.8). I will use a workaround for the
> moment (i.e. disable wide offset MEM on conditional moves).
> Does someone know if
On 06/12/13 09:30, Konstantin Vladimirov wrote:
> Hi,
>
> Consider code:
>
> int foo(char *t, char *v, int w)
> {
> int i;
>
> for (i = 1; i != w; ++i)
> {
> int x = i << 2;
> v[x + 4] = t[x + 4];
> }
>
> return 0;
> }
>
> Compile it to x86 (I used both gcc 4.7.2 and gcc 4.8.1) with options:
>
Any gnat official release ? Maybe gnat 7.2 beta is based on 4.8, I'll try to
get this one.
-Message d'origine-
De : Andrew Pinski [mailto:pins...@gmail.com]
Envoyé : vendredi 6 décembre 2013 09:54
À : BELBACHIR Selim
Cc : Jeff Law; gcc@gcc.gnu.org
Objet : Re: Controling reloads of movsi
Hi,
Example from x86 code was only for ease of reproduction. I am pretty
sure, this is architecture-independent issue. Say on ARM:
.L2:
mov ip, r3, asl #2
add ip, ip, #4
add r3, r3, #1
ldrb r4, [r0, ip] @ zero_extendqisi2
cmp r3, r2
strb r4, [r1, ip]
bne .L2
May be improved to:
.L2:
add r3, r3,
On Fri, Dec 6, 2013 at 5:47 AM, Trevor Saunders wrote:
> On Mon, Dec 02, 2013 at 12:16:18PM +0100, Richard Biener wrote:
>> On Sun, Dec 1, 2013 at 12:30 PM, Toon Moene wrote:
>> > http://gcc.gnu.org/ml/gcc-testresults/2013-12/msg1.html
>> >
>> > FAILED: Bootstrap (build config: lto; languages
On Fri, Dec 6, 2013 at 9:42 AM, Richard Sandiford
wrote:
> Eric Botcazou writes:
>>> Well, I think making the simplify-rtx code conditional on the target
>>> would be the wrong way to go. If we really can't live with it being
>>> unconditional then I think we should revert it. But like I say I
On Fri, Dec 06, 2013 at 12:30:54PM +0400, Konstantin Vladimirov wrote:
> Consider code:
>
> int foo(char *t, char *v, int w)
> {
> int i;
>
> for (i = 1; i != w; ++i)
> {
> int x = i << 2;
> v[x + 4] = t[x + 4];
> }
>
> return 0;
> }
This is either job of ivopts pass, dunno why it doesn't consi
On Fri, Dec 6, 2013 at 9:30 AM, Konstantin Vladimirov
wrote:
> Hi,
>
> Consider code:
>
> int foo(char *t, char *v, int w)
> {
> int i;
>
> for (i = 1; i != w; ++i)
> {
> int x = i << 2;
> v[x + 4] = t[x + 4];
> }
>
> return 0;
> }
>
> Compile it to x86 (I used both gcc 4.7.2 and gcc 4.8.1) with o
Hi,
nothing changes if everything is unsigned and we are guaranteed to not
raise UB on overflow:
unsigned foo(unsigned char *t, unsigned char *v, unsigned w)
{
unsigned i;
for (i = 1; i != w; ++i)
{
unsigned x = i << 2;
v[x + 4] = t[x + 4];
}
return 0;
}
yields:
.L5:
leal 0(,%eax,4), %edx
add
On Fri, Dec 6, 2013 at 11:19 AM, Konstantin Vladimirov
wrote:
> Hi,
>
> nothing changes if everything is unsigned and we are guaranteed to not
> raise UB on overflow:
>
> unsigned foo(unsigned char *t, unsigned char *v, unsigned w)
> {
> unsigned i;
>
> for (i = 1; i != w; ++i)
> {
> unsigned x =
Hi all,
We are re-targeting the gcc 4.8.1 to the 16 bit core ,where word =int
= short = pointer= 16 , char = 8 bit and long =32 bit.
We model the above requirement as
#define BITS_PER_UNIT 8
#define BITS_PER_WORD 16
#define UNITS_PER_WORD 2
#define POINTER_SIZE
Hi All ,
The below sample caught my attention i.e
int a ;
unsigned int b;
int func()
{
return a =b;
}
the compiler didn't warn me about the signed mismatch in the above case.
where as
int *a ;
unsigned int *b;
int func()
{
a =b;
return *a;
}
compiler warns me as
warning: pointer targets in a
On Fri, Dec 6, 2013 at 2:25 AM, Richard Biener
wrote:
> On Fri, Dec 6, 2013 at 11:19 AM, Konstantin Vladimirov
> wrote:
>> Hi,
>>
>> nothing changes if everything is unsigned and we are guaranteed to not
>> raise UB on overflow:
>>
>> unsigned foo(unsigned char *t, unsigned char *v, unsigned w)
>
On Wed, 4 Dec 2013, Vidya Praveen wrote:
> Hi Richi,
>
> Apologies for the late response. I was on vacation.
>
> On Mon, Oct 14, 2013 at 09:04:58AM +0100, Richard Biener wrote:
> > > void
> > > foo (int *__restrict__ a,
> > > int *__restrict__ b,
> > > int c)
> > > {
> > > int i;
> >
Umesh Kalappa writes:
> Tried to compile the below sample by retargeted compiler
>
> int a =10;
>
> int b =10;
>
>
> int func()
>
> {
>
> return a+ b;
>
> }
>
> the compiler is stating that the a and b are global with short type(HI
> mode) of size 2 bytes.
Yeah, HImode sounds right in this case.
On Fri, 6 Dec 2013, Konstantin Vladimirov wrote:
Consider code:
int foo(char *t, char *v, int w)
{
int i;
for (i = 1; i != w; ++i)
{
int x = i << 2;
A side note, but something too few people seem to be aware of: writing
i<<2 can pessimize code compared to i*4 (and it is never faster). That
Hi,
Richard, I tried to add LSHIFT_EXPR case to tree-scalar-evolution.c
and now it yields code like (x86 again):
.L5:
movzbl 4(%esi,%eax,4), %edx
movb %dl, 4(%ebx,%eax,4)
addl $1, %eax
cmpl %ecx, %eax
jne .L5
So, excessive lea is gone. It is great, thank you so much. But I
wonder what else can I
I am pleased to announce that the GCC Steering Committee has
appointed Oleg Endo as co-maintainer of the SH port.
Please join me in congratulating Oleg on his new role.
Oleg, please update your listing in the MAINTAINERS file.
Happy hacking!
David
On Fri, Dec 6, 2013 at 2:52 PM, Konstantin Vladimirov
wrote:
> Hi,
>
> Richard, I tried to add LSHIFT_EXPR case to tree-scalar-evolution.c
> and now it yields code like (x86 again):
>
> .L5:
> movzbl 4(%esi,%eax,4), %edx
> movb %dl, 4(%ebx,%eax,4)
> addl $1, %eax
> cmpl %ecx, %eax
> jne .L5
>
> So
On 12/06/2013 10:41 AM, Umesh Kalappa wrote:
> I’m bit confused or i'm missing something here .
The first of these is implementation-defined behaviour, and the second
is (potentially) undefined behaviour.
This is more of a generic C question than a GCC question.
Andrew.
On Dec 6, 2013, at 5:40 AM, Umesh Kalappa wrote:
> Hi all,
>
> We are re-targeting the gcc 4.8.1 to the 16 bit core ,where word =int
> = short = pointer= 16 , char = 8 bit and long =32 bit.
>
> We model the above requirement as
>
> #define BITS_PER_UNIT 8
>
> #define BITS_PER_WOR
On Fri, Dec 06, 2013 at 10:47:00AM +0100, Richard Biener wrote:
> On Fri, Dec 6, 2013 at 5:47 AM, Trevor Saunders wrote:
> > On Mon, Dec 02, 2013 at 12:16:18PM +0100, Richard Biener wrote:
> >> On Sun, Dec 1, 2013 at 12:30 PM, Toon Moene wrote:
> >> > http://gcc.gnu.org/ml/gcc-testresults/2013-12
On Fri, 2013-12-06 at 09:05 -0500, David Edelsohn wrote:
> I am pleased to announce that the GCC Steering Committee has
> appointed Oleg Endo as co-maintainer of the SH port.
>
> Please join me in congratulating Oleg on his new role.
> Oleg, please update your listing in the MAINTAINER
On 12/06/13 07:17, Richard Biener wrote:
On Fri, Dec 6, 2013 at 2:52 PM, Konstantin Vladimirov
wrote:
Hi,
Richard, I tried to add LSHIFT_EXPR case to tree-scalar-evolution.c
and now it yields code like (x86 again):
.L5:
movzbl 4(%esi,%eax,4), %edx
movb %dl, 4(%ebx,%eax,4)
addl $1, %eax
cmpl %
On 12/5/2013, 9:35 AM, Tejas Belagod wrote:
Vladimir Makarov wrote:
On 12/4/2013, 6:15 AM, Tejas Belagod wrote:
Hi,
I'm trying to relax CANNOT_CHANGE_MODE_CLASS for aarch64 to allow all
mode changes on FP_REGS as aarch64 does not have register-packing, but
I'm running into an LRA ICE. A test c
29 matches
Mail list logo
