> From: Richard Biener [mailto:richard.guent...@gmail.com]
> On Wed, Jun 4, 2014 at 9:04 AM, Thomas Preud'homme
> 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 feedback from C
On Wed, Jun 4, 2014 at 9:04 AM, Thomas Preud'homme
wrote:
>> From: Christophe Lyon [mailto:christophe.l...@linaro.org]
>> On 29 May 2014 11:58, Thomas Preud'homme
>> wrote:
>> >
>> > Does the patch solve the problem you had? What about you Christophe?
>> >
>> >
>>
>> Hi Thomas,
>>
>> After a quic
> From: Christophe Lyon [mailto:christophe.l...@linaro.org]
> On 29 May 2014 11:58, Thomas Preud'homme
> wrote:
> >
> > Does the patch solve the problem you had? What about you Christophe?
> >
> >
>
> Hi Thomas,
>
> After a quick test, it looks OK to me.
Great. What about you Andreas? Does it w
On 29 May 2014 11:58, Thomas Preud'homme wrote:
>> From: Andreas Schwab [mailto:sch...@linux-m68k.org]
>> "Thomas Preud'homme" 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 or
> From: Andreas Schwab [mailto:sch...@linux-m68k.org]
> "Thomas Preud'homme" 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 very awake when
"Thomas Preud'homme" 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 6D53 942B 1756 01D3 4
> 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 p
"Thomas Preud'homme" 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
> +++ b/gcc/testsuite/gcc.c-torture/execute/bswap-2.c
> @@ -6,8 +6,11
On 27 May 2014 09:23, Thomas Preud'homme 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
>> reduce 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 rig
> 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 i
On 23 May 2014 05:36, Thomas Preud'homme wrote:
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> On Wed, May 21, 2014 at 3:00 AM, Thomas Preud'homme
>> wrote:
>
>> >
>> > Updated ChangeLogs:
>> >
>> > *** gcc/ChangeLog ***
>> >
>> > 2014-05-20 Thomas Preud'homme
>> >
>> >
* 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
+++ b/gcc/testsuite/
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> On Wed, May 21, 2014 at 3:00 AM, Thomas Preud'homme
> wrote:
> >
> > Updated ChangeLogs:
> >
> > *** gcc/ChangeLog ***
> >
> > 2014-05-20 Thomas Preud'homme
> >
> > PR tree-optimization/54733
> > * tree-ssa-math-opts.
On Wed, May 21, 2014 at 3:00 AM, Thomas Preud'homme
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
> parameter instead of a
> 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]
>
> 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 opti
On Tue, May 20, 2014 at 4:46 AM, Thomas Preud'homme
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 (load_type), align).
>> [of
...
>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Thomas Preud'homme
>>>>>>
>>>>>>> -Original Message-
>>>>>>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-pat
> 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 "re
On Mon, May 19, 2014 at 11:30 AM, Thomas Preud'homme
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 zer
> 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
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> On Fri, May 16, 2014 at 12:07 PM, Thomas Preud'homme
> 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 that patches somet
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,
t;> wrote:
>>>> Ping?
>>>
>>> Sorry ...
>>>
>>>> Best regards,
>>>>
>>>> Thomas Preud'homme
>>>>
>>>>> -Original Message-
>>>>> From: gcc-patches-ow...@gcc.gnu.org [mailto:
rds,
>>>
>>> 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,
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 lo
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
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]
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
PR tree-opt
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 the
31 matches
Mail list logo
