Richard Biener writes:
> On Tue, 7 Jan 2020, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > On Tue, 7 Jan 2020, Andrew Pinski wrote:
>> >
>> >> On Mon, Jan 6, 2020 at 11:36 PM Richard Biener wrote:
>> >> >
>> >> > On Mon, 16 Dec 2019, Andrew Pinski wrote:
>> >> >
>> >> > > On Thu, Nov
On Tue, 7 Jan 2020, Richard Sandiford wrote:
> Richard Biener writes:
> > On Tue, 7 Jan 2020, Andrew Pinski wrote:
> >
> >> On Mon, Jan 6, 2020 at 11:36 PM Richard Biener wrote:
> >> >
> >> > On Mon, 16 Dec 2019, Andrew Pinski wrote:
> >> >
> >> > > On Thu, Nov 15, 2018 at 12:31 AM Richard Biene
Richard Biener writes:
> On Tue, 7 Jan 2020, Andrew Pinski wrote:
>
>> On Mon, Jan 6, 2020 at 11:36 PM Richard Biener wrote:
>> >
>> > On Mon, 16 Dec 2019, Andrew Pinski wrote:
>> >
>> > > On Thu, Nov 15, 2018 at 12:31 AM Richard Biener
>> > > wrote:
>> > > >
>> > > > On Thu, 15 Nov 2018, Richa
On Tue, 7 Jan 2020, Andrew Pinski wrote:
> On Mon, Jan 6, 2020 at 11:36 PM Richard Biener wrote:
> >
> > On Mon, 16 Dec 2019, Andrew Pinski wrote:
> >
> > > On Thu, Nov 15, 2018 at 12:31 AM Richard Biener wrote:
> > > >
> > > > On Thu, 15 Nov 2018, Richard Biener wrote:
> > > >
> > > > > On Wed,
On Mon, Jan 6, 2020 at 11:36 PM Richard Biener wrote:
>
> On Mon, 16 Dec 2019, Andrew Pinski wrote:
>
> > On Thu, Nov 15, 2018 at 12:31 AM Richard Biener wrote:
> > >
> > > On Thu, 15 Nov 2018, Richard Biener wrote:
> > >
> > > > On Wed, 14 Nov 2018, Andrew Pinski wrote:
> > > >
> > > > > On Fri,
On Mon, 16 Dec 2019, Andrew Pinski wrote:
> On Thu, Nov 15, 2018 at 12:31 AM Richard Biener wrote:
> >
> > On Thu, 15 Nov 2018, Richard Biener wrote:
> >
> > > On Wed, 14 Nov 2018, Andrew Pinski wrote:
> > >
> > > > On Fri, May 13, 2016 at 3:51 AM Richard Biener
> > > > wrote:
> > > > >
> > > >
On Mon, Dec 16, 2019 at 6:32 PM Andrew Pinski wrote:
>
> On Thu, Nov 15, 2018 at 12:31 AM Richard Biener wrote:
> >
> > On Thu, 15 Nov 2018, Richard Biener wrote:
> >
> > > On Wed, 14 Nov 2018, Andrew Pinski wrote:
> > >
> > > > On Fri, May 13, 2016 at 3:51 AM Richard Biener
> > > > wrote:
> >
On Thu, Nov 15, 2018 at 12:31 AM Richard Biener wrote:
>
> On Thu, 15 Nov 2018, Richard Biener wrote:
>
> > On Wed, 14 Nov 2018, Andrew Pinski wrote:
> >
> > > On Fri, May 13, 2016 at 3:51 AM Richard Biener wrote:
> > > >
> > > >
> > > > The following patch adds BIT_FIELD_INSERT, an operation to
On Thu, 15 Nov 2018, Richard Biener wrote:
> On Wed, 14 Nov 2018, Andrew Pinski wrote:
>
> > On Fri, May 13, 2016 at 3:51 AM Richard Biener wrote:
> > >
> > >
> > > The following patch adds BIT_FIELD_INSERT, an operation to
> > > facilitate doing bitfield inserts on registers (as opposed
> > > t
On Wed, 14 Nov 2018, Andrew Pinski wrote:
> On Fri, May 13, 2016 at 3:51 AM Richard Biener wrote:
> >
> >
> > The following patch adds BIT_FIELD_INSERT, an operation to
> > facilitate doing bitfield inserts on registers (as opposed
> > to currently where we'd have a BIT_FIELD_REF store).
> >
> >
On Fri, May 13, 2016 at 3:51 AM Richard Biener wrote:
>
>
> The following patch adds BIT_FIELD_INSERT, an operation to
> facilitate doing bitfield inserts on registers (as opposed
> to currently where we'd have a BIT_FIELD_REF store).
>
> Originally this was developed as part of bitfield lowering
On May 20, 2016 6:08:34 PM GMT+02:00, Jakub Jelinek wrote:
>On Fri, May 20, 2016 at 08:54:39AM -0700, Andi Kleen wrote:
>> I thought I had filed a bugzilla at some point, but can't
>> find it right now. If you compare bitfield code
>> compiled for Haswell on LLVM and GCC it is very visible
>> how
On Fri, 20 May 2016, Andi Kleen wrote:
On Fri, May 20, 2016 at 05:11:59PM +0200, Marc Glisse wrote:
On Fri, 20 May 2016, Andi Kleen wrote:
Richard Biener writes:
The following patch adds BIT_FIELD_INSERT, an operation to
facilitate doing bitfield inserts on registers (as opposed
to current
On Fri, May 20, 2016 at 08:54:39AM -0700, Andi Kleen wrote:
> I thought I had filed a bugzilla at some point, but can't
> find it right now. If you compare bitfield code
> compiled for Haswell on LLVM and GCC it is very visible
> how much worse gcc is.
We really need to lower bitfield operations (
On Fri, May 20, 2016 at 05:11:59PM +0200, Marc Glisse wrote:
> On Fri, 20 May 2016, Andi Kleen wrote:
>
> >Richard Biener writes:
> >
> >>The following patch adds BIT_FIELD_INSERT, an operation to
> >>facilitate doing bitfield inserts on registers (as opposed
> >>to currently where we'd have a BI
On Fri, 20 May 2016, Andi Kleen wrote:
Richard Biener writes:
The following patch adds BIT_FIELD_INSERT, an operation to
facilitate doing bitfield inserts on registers (as opposed
to currently where we'd have a BIT_FIELD_REF store).
I wonder if these patches would make it easier to use the
Richard Biener writes:
> The following patch adds BIT_FIELD_INSERT, an operation to
> facilitate doing bitfield inserts on registers (as opposed
> to currently where we'd have a BIT_FIELD_REF store).
I wonder if these patches would make it easier to use the Haswell
bit manipulations instructions
On Fri, 20 May 2016, Jakub Jelinek wrote:
> On Fri, May 20, 2016 at 01:41:01PM +0200, Richard Biener wrote:
> > I'd say ppc and aarch64 are fine. Thanks for noticing.
>
> So like this then?
Yes.
Thanks,
Richard.
> 2016-05-20 Jakub Jelinek
>
> PR tree-optimization/29756
> gcc.d
On Fri, May 20, 2016 at 01:41:01PM +0200, Richard Biener wrote:
> I'd say ppc and aarch64 are fine. Thanks for noticing.
So like this then?
2016-05-20 Jakub Jelinek
PR tree-optimization/29756
gcc.dg/tree-ssa/vector-6.c: Add -Wno-psabi -w to dg-options.
Add -msse2 for
On Fri, 20 May 2016, Jakub Jelinek wrote:
> On Fri, May 20, 2016 at 10:59:18AM +0200, Richard Biener wrote:
> > Sounds good. I will commit later with your wording.
>
> Unfortunately, the new testcase fails e.g. on i?86-*-* or on powerpc*.
> On i?86-*-* (without -msse) I actually see 2 different
On Fri, May 20, 2016 at 10:59:18AM +0200, Richard Biener wrote:
> Sounds good. I will commit later with your wording.
Unfortunately, the new testcase fails e.g. on i?86-*-* or on powerpc*.
On i?86-*-* (without -msse) I actually see 2 different issues, one is
extra -Wpsabi warnings, and another is
On Thu, 19 May 2016, Eric Botcazou wrote:
> > Index: trunk/gcc/tree.def
> > ===
> > *** trunk.orig/gcc/tree.def 2016-05-17 17:19:41.783958489 +0200
> > --- trunk/gcc/tree.def 2016-05-19 10:23:35.779141973 +0200
> > **
> Index: trunk/gcc/tree.def
> ===
> *** trunk.orig/gcc/tree.def 2016-05-17 17:19:41.783958489 +0200
> --- trunk/gcc/tree.def2016-05-19 10:23:35.779141973 +0200
> *** DEFTREECODE (ADDR_EXPR, "addr_expr", tcc
> ***
On Tue, 17 May 2016, Michael Matz wrote:
> Hi,
>
> On Tue, 17 May 2016, Richard Biener wrote:
>
> > BIT_INSERT_EXPR
>
> This.
>
> > Any preference?
Here is an updated patch.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
I plan to commit this tomorrow if there are no further comments
Hi,
On Tue, 17 May 2016, Richard Biener wrote:
> BIT_INSERT_EXPR
This.
> Any preference?
Ciao,
Michael.
> I'm fine with renaming it to BIT_FIELD_INSERT_EXPR, maybe
> BIT_INSERT_EXPR then as it doesn't really have anything to do
> with "bitfields".
>
> Any preference?
BIT_INSERT_EXPR is fine with me.
--
Eric Botcazou
On Mon, 16 May 2016, Bill Schmidt wrote:
> Sorry, that was the wrong vector-6.c — should have realized. In any
> case, for each of the vector tests, we get appropriate use of
> element-wise loads, and no load-hit-store bitfield assignments, so the
> code generation is what we want to see. Sor
On Mon, 16 May 2016, Eric Botcazou wrote:
> > The following patch adds BIT_FIELD_INSERT, an operation to
> > facilitate doing bitfield inserts on registers (as opposed
> > to currently where we'd have a BIT_FIELD_REF store).
>
> Why not call it BIT_FIELD_INSERT_EXPR instead to make it clear that
Sorry, that was the wrong vector-6.c — should have realized. In any case, for
each of the vector tests, we get appropriate use of element-wise loads, and no
load-hit-store bitfield assignments, so the code generation is what we want to
see. Sorry for the misleading information.
Bill
> On May
> The following patch adds BIT_FIELD_INSERT, an operation to
> facilitate doing bitfield inserts on registers (as opposed
> to currently where we'd have a BIT_FIELD_REF store).
Why not call it BIT_FIELD_INSERT_EXPR instead to make it clear that it's an
expression and not a mere operation?
> Orig
Hi Richard,
(Sorry for duplication to your personal email, I had new-mailer issues.)
The new vector-6 test produces very good code for powerpc64le with this patch:
addis 9,2,.LC0@toc@ha
sldi 3,3,32
addi 9,9,.LC0@toc@l
rldicl 9,9,0,32
or 3,9,3
blr
The following patch adds BIT_FIELD_INSERT, an operation to
facilitate doing bitfield inserts on registers (as opposed
to currently where we'd have a BIT_FIELD_REF store).
Originally this was developed as part of bitfield lowering
where bitfield stores were lowered into read-modify-write
cycles an
32 matches
Mail list logo
