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
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
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 guys
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, works
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 other is
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 mean
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
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!
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 don't
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:
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 what
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?
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
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
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:
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 the
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
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 alias
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:
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
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 changing that!
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;};
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...
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;
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 *claim* X is nonaddressable.
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 nonaddressable.
I don't
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 variable.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]))
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 = bar.
foop-x = 5.
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 assigment to *pi can't
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;
and mark X as
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
J :
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 above. foop is a pointer to bar.x
in
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
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't
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
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
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
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 pointer
get_alias_set and internally record_component_aliases makes
assumptions about the IR that are only valid in RTL. As a consequence
the constant 1 is propagated into the function call in the example
below (I found this issue with 4.1 but it is also present on trunk):
struct s
{
long long
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?
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 set 0.
For
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-addressable
42 matches
Mail list logo
