> > I continue to strongly feel that the field type shouldn't be used
> > for ANYTHING!
>
> Then you will continue to get worse code generation than you could, in
> addition to bugs like we have now.
Explain to me why in the following case:
struct s1 {int a;};
struct s2 {short a;
> > struct foo {int a: 32; int b: 32; };
> > struct bar {int c: 32; int d: 32; };
> >
> > you have the fields A and C conflicting, which is wrong.
>
> With the current scheme you have fields a and b conflict
> and c and d conflicting
>
> Both of which are wrong
But nothing is cha
On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > you have the fields A and C conflicting, which is wrong.
>
> Well, that is where structure-field aliasing comes in. The two cannot
> even alias for addressable fields:
At tree level I'll take your word for it, but what about RTL level?
I
On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Type of the expression passed to get_alias_set. And without the
> component_uses_parent_alias_set loop.
So you mean the type of the *field*? That can't work. That type can't
be used for *anything*!
Otherwise, if you have
struct
On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> They are the alias set mechanism, which you don't seem to understand.
> They always have been.
I certainly understand the alias set mechanism. It sounded like you were
talking about something else since if the only thing we're using is ali
> > you have the fields A and C conflicting, which is wrong.
>
> Well, that is where structure-field aliasing comes in. The two cannot
> even alias for addressable fields:
At tree level I'll take your word for it, but what about RTL level?
Is that nonconflicting status passed to RTL? What *is*
Richard Kenner writes:
> Otherwise, if you have
>
> struct foo {int a: 32; int b: 32; };
> struct bar {int c: 32; int d: 32; };
>
> you have the fields A and C conflicting, which is wrong.
Well, that is where structure-field aliasing comes in. The two cannot
even alias for addressab
> They are the alias set mechanism, which you don't seem to understand.
> They always have been.
I certainly understand the alias set mechanism. It sounded like you were
talking about something else since if the only thing we're using is alias
sets, I'm mystified as to what the issue is.
> I'd r
On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> It gives you the alias set of the parent, which, for the reason that
> OTHER THINGS USE THE ALIAS SET SPLAY TREES, gives the wrong answer.
Can you give a few sentence explanation of what "alias set splay trees"
are and why they aren't using
> Type of the expression passed to get_alias_set. And without the
> component_uses_parent_alias_set loop.
So you mean the type of the *field*? That can't work. That type can't
be used for *anything*!
Otherwise, if you have
struct foo {int a: 32; int b: 32; };
struct bar {int c
Richard Kenner writes:
> > I am glad to see we are converging toward implementation issues now!
> >
> > I am storing it in a new field under the alias_set_entry:
> >
> > get_alias_set_entry (TYPE_ALIAS_SET (t))->nonaddr_alias_set.
>
> Where T is which type?
Type of the expression passed to g
> It gives you the alias set of the parent, which, for the reason that
> OTHER THINGS USE THE ALIAS SET SPLAY TREES, gives the wrong answer.
Can you give a few sentence explanation of what "alias set splay trees"
are and why they aren't using the alias set mechanism?
> > I'm not sure what a "TBAA
> I am glad to see we are converging toward implementation issues now!
>
> I am storing it in a new field under the alias_set_entry:
>
> get_alias_set_entry (TYPE_ALIAS_SET (t))->nonaddr_alias_set.
Where T is which type?
On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> How does this get a different result for trees than RTL?
>
> As i've explained, we rely on the proper of the TBAA forest that given
>
> struct foo (set 1)
> / \
> int :31 (set 2) short :31 (set 3)
>
> se
Richard Kenner writes:
> But there's also an implementation issue: where do you propose to *store*
> this fake alias set? There is no such field as DECL_ALIAS_SET.
I am glad to see we are converging toward implementation issues now!
I am storing it in a new field under the alias_set_entry:
ge
> How does this get a different result for trees than RTL?
>
> As i've explained, we rely on the proper of the TBAA forest that given
>
> struct foo (set 1)
> / \
> int :31 (set 2) short :31 (set 3)
>
> sets for int :31 and short :31 are strict subsets of th
On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > But throws away the entire DECL_NONADDRESSABLE_P mechanism!
>
> No, an int* will still not conflict with int:31
> a short * will still not conflict with short:31
Using what mechanism? That's what DECL_NONADDRESSABLE_P does!
Please read
> > But throws away the entire DECL_NONADDRESSABLE_P mechanism!
>
> No, an int* will still not conflict with int:31
> a short * will still not conflict with short:31
Using what mechanism? That's what DECL_NONADDRESSABLE_P does!
> Tell me what TYPE_NONALIASED_COMPONENT does, and i'll tell you wh
On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> His first patch, which simply makes #1 true, would cause missed optimization.
It doesn't "cause missed optimizations": it completely removes all the
functionality of DECL_NONADDRESSABLE_P!
Hence the reason for the second suggestion.
On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Again, the tree level relies on the documented (in the comments of
> alias.c) fact that given a structure, the fields contained in a
> structure will have alias sets that are strict subsets of the parent.
That is ONLY true for fields that d
> His first patch, which simply makes #1 true, would cause missed optimization.
It doesn't "cause missed optimizations": it completely removes all the
functionality of DECL_NONADDRESSABLE_P!
> Again, the tree level relies on the documented (in the comments of
> alias.c) fact that given a structure, the fields contained in a
> structure will have alias sets that are strict subsets of the parent.
That is ONLY true for fields that don't have DECL_NONADDRESSABLE_P
and that's been the case
On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Uh, except as we've discovered, the RTL uses alias set 0, so whatever
> alias set you choose for these doesn't matter anyway to the RTL level.
Only in some cases. That was a kludge put in to fix some obscure bug and
left there. I hope we c
> Uh, except as we've discovered, the RTL uses alias set 0, so whatever
> alias set you choose for these doesn't matter anyway to the RTL level.
Only in some cases. That was a kludge put in to fix some obscure bug and
left there. I hope we can remove it at some point, and think we can.
> No i me
On 6/18/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 6/18/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > If it was designed properly in the first place, there simply would *be
> > no problem at the tree level*, because nothing would have broken.
>
> That's certainly a point of view. The oth
On 6/18/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> If it was designed properly in the first place, there simply would *be
> no problem at the tree level*, because nothing would have broken.
That's certainly a point of view. The other is that the RTL implementation
predates the Tree one, wor
> If it was designed properly in the first place, there simply would *be
> no problem at the tree level*, because nothing would have broken.
It's possible to have bugs anytime and that's all we have here: somebody
is using the wrong alias set someplace. We fix that and all is OK.
> So far you gu
> That is not the example case we have given where this breaks.
> The case where it breaks is exactly the case i have shown you.
>
> We have a pointer to a structure, and because you have not recorded
> the type's alias relationships properly, we claim derferences that are
> offsetted from the str
> If it was designed properly in the first place, there simply would *be
> no problem at the tree level*, because nothing would have broken.
That's certainly a point of view. The other is that the RTL implementation
predates the Tree one, works fine in GCC 3.x, including for the C compiler.
One
On 6/18/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> I'm completely unsurprised this is broken at the tree level given how
> it is implemented
Nice tautology. :-) You have resisted implementing anything at the tree level
to fix the problem and now you're complaining there is a problem...
Pa
> I'm completely unsurprised this is broken at the tree level given how
> it is implemented
Nice tautology. :-) You have resisted implementing anything at the tree level
to fix the problem and now you're complaining there is a problem...
Let's try and devise something plausible at the tree leve
> I am trying now to prototype a new approach along the lines of
> returning true in component_uses_parent_alias_set for SFT's with
> DECL_NONADDRESSABLE_P.
Yes, the key problem is indeed SFTs, which is why we disable structure
aliasing in the Ada compiler.
--
Eric Botcazou
> > type T1 is record
> >J : Integer;
> > end record;
> >
> > X1 : T1;
> >
> > => then X1.J "address" cannot be taken in legal Ada, so no integer
> > pointer can ever point to it.
>
> However, can a pointer to X1, stored into, affect J?
Of course.
> If so, field J's alias set must be marked
On 6/17/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > > > So if I have
> > > > struct foo {int x; float y; } bar;
> > >
> > > But if you add
> > >
> > > struct foo *foop = &bar.
> > >
> > > foop->x = 5.
> > >
> > > It can, even though we *claim* X is nonaddressable.
> >
> > Which can
> > > > So if I have
> > > > struct foo {int x; float y; } bar;
> > >
> > > But if you add
> > >
> > > struct foo *foop = &bar.
> > >
> > > foop->x = 5.
> > >
> > > It can, even though we *claim* X is nonaddressable.
> >
> > Which can what exactly?
>
> It can be addressed, as i've shown ab
On Sun, 2007-06-17 at 17:02 -0400, Daniel Berlin wrote:
> On 6/17/07, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > In Ada if you have a struct type, components of the struct
> > that do not have the explicit keyword "aliased" cannot
> > have their adress taken. Example:
> >
> > type T1 is record
>
On 6/17/07, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
On Sun, 2007-06-17 at 15:31 -0400, Daniel Berlin wrote:
> On 6/17/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > > > So if I have
> > > > struct foo {int x; float y; } bar;
> > > > int *pi;
> > > > float *pf;
> > > >
On Sun, 2007-06-17 at 15:31 -0400, Daniel Berlin wrote:
> On 6/17/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > > > So if I have
> > > > struct foo {int x; float y; } bar;
> > > > int *pi;
> > > > float *pf;
> > > >
> > > > and mark X as "nonaddressable", I know that an a
On 6/17/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > So if I have
> > struct foo {int x; float y; } bar;
> > int *pi;
> > float *pf;
> >
> > and mark X as "nonaddressable", I know that an assigment to *pi can't
> > affect bar.x.
>
> But if you add
>
> struct foo *foop
Eric Botcazou writes:
> For the Ada testcase:
>
> ;; s->i = 0
> (insn 7 6 0 p.adb:5 (set (mem/s/j:SI (reg/v/f:DI 59 [ s ]) [4 .i+0
> S4 A32])
> (const_int 0 [0x0])) -1 (nil))
>
> ;; *p = 1
> (insn 8 7 0 p.adb:6 (set (mem:SI (reg/v/f:DI 60 [ p ]) [2 S4 A32])
> (const_int 1 [0x1]))
> > struct foo {int x; float y; } bar;
> > int *pi;
> > float *pf;
> >
> > and mark X as "nonaddressable", I know that an assigment to *pi can't
> > affect bar.x.
>
> But if you add
>
> struct foo *foop = &bar.
>
> foop->x = 5.
>
> It can, even though we *claim* X is non
> > So if I have
> > struct foo {int x; float y; } bar;
> > int *pi;
> > float *pf;
> >
> > and mark X as "nonaddressable", I know that an assigment to *pi can't
> > affect bar.x.
>
> But if you add
>
> struct foo *foop = &bar.
>
> foop->x = 5.
>
> It can, even though we *cl
> Because it wouldn't be pruning it if the alias sets conflicted!
Well, just look at the first RTL dump for:
struct S { int i; };
int f (struct S *s, int *p)
{
s->i = 0;
*p = 1;
return s->i;
}
and
package P is
type S is record
i : Integer;
end record;
type SP is access all S;
On 6/16/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> You guys have come up with a very weird idea of what
> non-addressability means. These fields are all addressable, they
> are just not directly addressable.
Terminology is always tricky here. "addressable" in this context means
that no po
On 6/16/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> If that was really true, we would get this right.
Well, this is true, I really don't understand why you keep denying that.
Because it wouldn't be pruning it if the alias sets conflicted!
Just grep the RTL expanders for MEM_KEEP_ALIAS_SE
> You guys have come up with a very weird idea of what
> non-addressability means. These fields are all addressable, they
> are just not directly addressable.
Terminology is always tricky here. "addressable" in this context means
that no pointer can point directly to the field.
So if I have
> If that was really true, we would get this right.
Well, this is true, I really don't understand why you keep denying that.
Just grep the RTL expanders for MEM_KEEP_ALIAS_SET_P for example:
`MEM_KEEP_ALIAS_SET_P (X)'
In `mem' expressions, 1 if we should keep the alias set for this
mem
On 6/16/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> HMm, i'd just record it for all of them, since the [fields] are accessible
> through a pointer to the structure.
They are indeed accessible this way...
> Just because you can't directly take the address of a bitfield doesn't
> mean you can'
> HMm, i'd just record it for all of them, since the [fields] are accessible
> through a pointer to the structure.
They are indeed accessible this way...
> Just because you can't directly take the address of a bitfield doesn't
> mean you can't access one through a pointer, which is the entire
> p
On 6/15/07, Adam Nemet <[EMAIL PROTECTED]> wrote:
Daniel Berlin writes:
> On 6/15/07, Adam Nemet <[EMAIL PROTECTED]> wrote:
> > get_alias_set and internally record_component_aliases makes
> > assumptions about the IR that are only valid in RTL.
>
> What is this assumption, exactly?
That non-addr
Daniel Berlin writes:
> On 6/15/07, Adam Nemet <[EMAIL PROTECTED]> wrote:
> > get_alias_set and internally record_component_aliases makes
> > assumptions about the IR that are only valid in RTL.
>
> What is this assumption, exactly?
That non-addressable fields are always accessed through alias se
On 6/15/07, Adam Nemet <[EMAIL PROTECTED]> wrote:
get_alias_set and internally record_component_aliases makes
assumptions about the IR that are only valid in RTL.
What is this assumption, exactly?
52 matches
Mail list logo
