On Mar 10, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On Mon, 10 Mar 2008, Alexandre Oliva wrote:
>> The reason SRA generates more IL is *precisely* to get better
>> optimization. The back-ends don't handle BIT_FIELD_REFs very well.
> So I thought they can do bit-field stores...? no?
On Mon, 10 Mar 2008, Alexandre Oliva wrote:
> On Mar 9, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote:
>
> > On Sun, 9 Mar 2008, Alexandre Oliva wrote:
> >> AM33/2.0 and H8SX come to mind, although it's been a while since I
> >> dealt with the memory bit-field operations of these two ports to
Alexandre Oliva wrote:
On Mar 9, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote:
On Sun, 9 Mar 2008, Alexandre Oliva wrote:
AM33/2.0 and H8SX come to mind, although it's been a while since I
dealt with the memory bit-field operations of these two ports to have
the details handy.
Ok, I wo
On Mar 9, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On Sun, 9 Mar 2008, Alexandre Oliva wrote:
>> AM33/2.0 and H8SX come to mind, although it's been a while since I
>> dealt with the memory bit-field operations of these two ports to have
>> the details handy.
> Ok, I would expect it a
On Sun, 9 Mar 2008, Alexandre Oliva wrote:
> On Mar 9, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote:
>
> > On Sun, 9 Mar 2008, Alexandre Oliva wrote:
> >> Do you have any plans to recover the performance loss for machines
> >> that have bit-field instructions that operate directly in memory?
On Mar 9, 2008, Eric Botcazou <[EMAIL PROTECTED]> wrote:
>> I meant Ada can have non-integral members that are do not occupy an
>> integral number of bytes.
> Right, but the middle-end shouldn't need to touch them globally, the
> front-end is supposed to break up the accesses.
My point is that
On Mar 9, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On Sun, 9 Mar 2008, Alexandre Oliva wrote:
>> Do you have any plans to recover the performance loss for machines
>> that have bit-field instructions that operate directly in memory?
>> Especially for writes, I don't see how this is goi
> I meant Ada can have non-integral members that are do not occupy an
> integral number of bytes.
Right, but the middle-end shouldn't need to touch them globally, the front-end
is supposed to break up the accesses.
--
Eric Botcazou
On Sun, 9 Mar 2008, Alexandre Oliva wrote:
> On Mar 8, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 8 Mar 2008, Alexandre Oliva wrote:
> >> > the object referenced is of integral type
>
> >> This would break the use of SRA to extract sub-objects of non-integral
> >> type. II
On Mar 8, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On Sat, 8 Mar 2008, Alexandre Oliva wrote:
>> > the object referenced is of integral type
>> This would break the use of SRA to extract sub-objects of non-integral
>> type. IIRC Ada does such things.
> No frontend generates BIT_FIEL
On Sat, 8 Mar 2008, Alexandre Oliva wrote:
> On Mar 4, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote:
>
> > the type of the result is unspecified.
>
> ??? You mean, other than by TREE_TYPE of the BIT_FIELD_REF? I'm
> pretty sure that's what specifies the type of the result.
You are late,
On Mar 4, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote:
> the type of the result is unspecified.
??? You mean, other than by TREE_TYPE of the BIT_FIELD_REF? I'm
pretty sure that's what specifies the type of the result.
> I suggest to make sure that bit position and size are constants,
+1
On Tue, 4 Mar 2008, Andrew Pinski wrote:
> On 3/4/08, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > I suggest to make sure that bit position and size are constants, the
> > object referenced is of integral type (BIT_FIELD_REF should not be
> > used as a way to circumvent aliasing) and the res
On 3/4/08, Richard Guenther <[EMAIL PROTECTED]> wrote:
> I suggest to make sure that bit position and size are constants, the
> object referenced is of integral type (BIT_FIELD_REF should not be
> used as a way to circumvent aliasing) and the result type is of the
> same type as the operand zer
On Tue, 4 Mar 2008, Jakub Jelinek wrote:
> On Tue, Mar 04, 2008 at 11:15:00AM -0500, Diego Novillo wrote:
> > >fold currently optimizes a.b.c == 0 to BIT_FIELD_REF & 1
> > >for bit field field-decls c. IMHO this is bad because it pessimizes
> > >TBAA (needs to use a's alias set, not the underlyi
On Tue, Mar 04, 2008 at 11:15:00AM -0500, Diego Novillo wrote:
> >fold currently optimizes a.b.c == 0 to BIT_FIELD_REF & 1
> >for bit field field-decls c. IMHO this is bad because it pessimizes
> >TBAA (needs to use a's alias set, not the underlying integral type
> >alias set) and it "breaks" typ
On 3/4/08 10:55 AM, Richard Guenther wrote:
I suggest to make sure that bit position and size are constants, the
object referenced is of integral type (BIT_FIELD_REF should not be
used as a way to circumvent aliasing) and the result type is of the
same type as the operand zero type (and not a bi
17 matches
Mail list logo
