From: Richard Biener [mailto:richard.guent...@gmail.com]
On Wed, Jun 4, 2014 at 9:04 AM, Thomas Preud'homme
thomas.preudho...@arm.com wrote:
Great. What about you Andreas? Does it work fine for you? If yes, is this ok
for trunk?
Ok.
Thanks,
Richard.
Commited since I got positive
On Wed, Jun 4, 2014 at 9:04 AM, Thomas Preud'homme
thomas.preudho...@arm.com wrote:
From: Christophe Lyon [mailto:christophe.l...@linaro.org]
On 29 May 2014 11:58, Thomas Preud'homme
thomas.preudho...@arm.com wrote:
Does the patch solve the problem you had? What about you Christophe?
On 29 May 2014 11:58, Thomas Preud'homme thomas.preudho...@arm.com wrote:
From: Andreas Schwab [mailto:sch...@linux-m68k.org]
Thomas Preud'homme thomas.preudho...@arm.com writes:
By the way, I couldn't understand how you reached the value
0x44434241. Can you explain me?
Each byte is
From: Andreas Schwab [mailto:sch...@linux-m68k.org]
This adds a full byte of padding between each bitfield. If you want a
single padding bit you should use :1, but you also need to update the
test to check for 0x44434241 (0x88868482 is impossible, since that
requires at least 8 bits per
Thomas Preud'homme thomas.preudho...@arm.com writes:
By the way, I couldn't understand how you reached the value
0x44434241. Can you explain me?
Each byte is composed of the first 7 bits of the original byte.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7
From: Andreas Schwab [mailto:sch...@linux-m68k.org]
Thomas Preud'homme thomas.preudho...@arm.com writes:
By the way, I couldn't understand how you reached the value
0x44434241. Can you explain me?
Each byte is composed of the first 7 bits of the original byte.
Sorry, it seems I wasn't
Hi Chistophe and Andreas,
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
I suspect it's the same kind of problem m68k run into. I already wrote a patch
to
reduce the impact of different bitfield layout and it's in review right
On 27 May 2014 09:23, Thomas Preud'homme thomas.preudho...@arm.com wrote:
Hi Chistophe and Andreas,
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
I suspect it's the same kind of problem m68k run into. I already wrote a
patch
to
Thomas Preud'homme thomas.preudho...@arm.com writes:
diff --git a/gcc/testsuite/gcc.c-torture/execute/bswap-2.c
b/gcc/testsuite/gcc.c-torture/execute/bswap-2.c
index 38f18fd..4368d83 100644
--- a/gcc/testsuite/gcc.c-torture/execute/bswap-2.c
+++
On 23 May 2014 05:36, Thomas Preud'homme thomas.preudho...@arm.com wrote:
From: Richard Biener [mailto:richard.guent...@gmail.com]
On Wed, May 21, 2014 at 3:00 AM, Thomas Preud'homme
thomas.preudho...@arm.com wrote:
Updated ChangeLogs:
*** gcc/ChangeLog ***
2014-05-20 Thomas
From: Christophe Lyon [mailto:christophe.l...@linaro.org]
I have noticed that the new bswap-2.c test fails at execution on armeb
targets.
See:
http://cbuild.validation.linaro.org/build/cross-validation/gcc/210843/report-
build-info.html
Could you have a look?
Sure.
I suspect it's the
* gcc.c-torture/execute/bswap-2.c (main): Handle more bitfield
layouts.
diff --git a/gcc/testsuite/gcc.c-torture/execute/bswap-2.c
b/gcc/testsuite/gcc.c-torture/execute/bswap-2.c
index e91b487..38f18fd 100644
--- a/gcc/testsuite/gcc.c-torture/execute/bswap-2.c
+++
On Wed, May 21, 2014 at 3:00 AM, Thomas Preud'homme
thomas.preudho...@arm.com wrote:
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
I'll send the new patch as soon as all the tests are done.
Here you are. I also simplified the tests a bit having the reference as a
function
From: Richard Biener [mailto:richard.guent...@gmail.com]
On Wed, May 21, 2014 at 3:00 AM, Thomas Preud'homme
thomas.preudho...@arm.com wrote:
Updated ChangeLogs:
*** gcc/ChangeLog ***
2014-05-20 Thomas Preud'homme thomas.preudho...@arm.com
PR tree-optimization/54733
On Tue, May 20, 2014 at 4:46 AM, Thomas Preud'homme
thomas.preudho...@arm.com wrote:
From: Richard Biener [mailto:richard.guent...@gmail.com]
Agreed, but I am happy with doing that as a followup. Btw,
a very simple one would be to reject unaligned
SLOW_UNALIGNED_ACCESS (TYPE_MODE
From: Richard Biener [mailto:richard.guent...@gmail.com]
It may do three aligned loads, char, short, char and combine them
while doing an unaligned int load may end up being slower. Though
very probable the RTL expansion machinery for unaligned loads
is way more clever to emit an optimal
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
I'll send the new patch as soon as all the tests are done.
Here you are. I also simplified the tests a bit having the reference as a
function
parameter instead of a local one.
Updated ChangeLogs:
*** gcc/ChangeLog ***
2014-05-20
From: Richard Biener [mailto:richard.guent...@gmail.com]
Oh, and what happens for
unsigned foo (unsigned char *x)
{
return x[0] 24 | x[2] 8 | x[3];
}
? We could do an unsigned int load from x and zero byte 3
with an AND. Enhancement for a followup, similar to also
considering
On Mon, May 19, 2014 at 11:30 AM, Thomas Preud'homme
thomas.preudho...@arm.com wrote:
From: Richard Biener [mailto:richard.guent...@gmail.com]
Oh, and what happens for
unsigned foo (unsigned char *x)
{
return x[0] 24 | x[2] 8 | x[3];
}
? We could do an unsigned int load from x and
From: Richard Biener [mailto:richard.guent...@gmail.com]
Agreed, but I am happy with doing that as a followup. Btw,
a very simple one would be to reject unaligned
SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align).
[of course that may be true on MIPS even for the cases where
a
-patches-
ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
Sent: Friday, May 09, 2014 6:26 PM
To: GCC Patches
Subject: RE: [PATCH] Fix PR54733 Optimize endian independent load/store
Sorry, took longer than expected as I got distracted by some other
patch.
I merged the whole patchset
From: Richard Biener [mailto:richard.guent...@gmail.com]
On Fri, May 16, 2014 at 12:07 PM, Thomas Preud'homme
thomas.preudho...@arm.com wrote:
Ping?
Sorry ...
Thanks and sorry again for the delay.
No need to be sorry, it was really not meant as a complaint. I understand very
well
Ping?
Best regards,
Thomas Preud'homme
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
Sent: Friday, May 09, 2014 6:26 PM
To: GCC Patches
Subject: RE: [PATCH] Fix PR54733 Optimize endian independent
09, 2014 6:26 PM
To: GCC Patches
Subject: RE: [PATCH] Fix PR54733 Optimize endian independent load/store
Sorry, took longer than expected as I got distracted by some other patch.
I merged the whole patchset in a single patch as I was told the current setup
is actually more difficult to read
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
Sent: Friday, May 09, 2014 6:26 PM
To: GCC Patches
Subject: RE: [PATCH] Fix PR54733 Optimize endian independent load/store
Sorry, took longer than expected as I got
Optimize endian independent load/store
Sorry, took longer than expected as I got distracted by some other patch.
I merged the whole patchset in a single patch as I was told the current
setup
is actually more difficult to read.
Here are the updated ChangeLogs:
*** gcc/ChangeLog ***
2014-05
Preud'homme
Sent: Friday, May 09, 2014 6:26 PM
To: GCC Patches
Subject: RE: [PATCH] Fix PR54733 Optimize endian independent load/store
Sorry, took longer than expected as I got distracted by some other patch.
I merged the whole patchset in a single patch as I was told the current
setup
Sorry, took longer than expected as I got distracted by some other patch.
I merged the whole patchset in a single patch as I was told the current setup
is actually more difficult to read.
Here are the updated ChangeLogs:
*** gcc/ChangeLog ***
2014-05-09 Thomas Preud'homme
Hi everybody,
*** Motivation ***
Currently gcc is capable of replacing hand-crafted implementation of byteswap
by a suitable instruction thanks to the bswap optimization pass. The patch
proposed here aims at extending this pass to also optimize load in a specific
endianness, independent of
29 matches
Mail list logo
