Displaying 20 results from an estimated 20000 matches similar to: "Aliasing rules difference between GCC and Clang"
2019 Jan 18
2
Aliasing rules difference between GCC and Clang
Hi Ivan,
On 2019-01-17 18:09, Ivan Kosarev wrote:
> Hello, Jonas,
>
> > It seems that when the struct member is an array, the base type
> > becomes the element type. This is simply unhandled still in
> > CodeGenTBAA ("TODO"). My question then is if it would be
> > possible to instead create the DAG nodes !"A" and !"B" (as in
> >
2012 Jan 24
2
[LLVMdev] Pointer aliasing
Hi Roel,
the code you list below is precisely what I expect to get (of course
the stores must happen but the constant folding should happen as
well).
It all looks very strange. LLVM is behaving as if the __restrict__
keyword was not used at all. Even more strange is the fact that for
this function:
double f(double *__restrict__ x, double *__restrict__ y, double *__restrict__ z)
{
*x = 1.0;
2015 Dec 09
2
Field sensitive alias analysis?
Hi Daniel,
I see your point about LLVM and C/C++ type agnostic. I think TBAA was
invented to partially cover this gap and give optimization opportunities
when LLVM types are not sufficient but C/C++ types have required
information.
What do you think about following example:
struct S {
int a[10];
int b;
};
int foo(struct S *ps, int i) {
ps->a[i] = 1;
ps->b = 2;
return
2012 Jan 23
2
[LLVMdev] Pointer aliasing
Hi LLVMers,
I would like to ask a question regarding aliasing. Suppose I have the
following program:
double f(double** p )
{
double a,b,c;
double * x = &a;
double * y = &b;
double * z = &c;
*x = 1;
*y = *x + 2;
*z = *x + 3;
return *x+*y+*z;
}
LLVM can tell that the three pointers do not alias each other so can
perform the constant folding at compile time.
2012 Jan 24
2
[LLVMdev] Pointer aliasing
I think the problem here is that the IR doesn't have any way to attach restrict information to loads/stores/pointers.
It works on arguments because they can be given the 'noalias' attribute, and then the alias analyzer must understand what that means.
Pete
On Jan 24, 2012, at 7:47 AM, Roel Jordans wrote:
> I have no clue, I didn't have time to look into that example yet.
2015 Dec 08
2
Field sensitive alias analysis?
Jeroen, thank you for very useful link with the context. Indeed union cases
are very complicated and I see places in code when TBAA gives up.
Daniel, I completely agree that TBAA has limited power and can solve
relatively simple cases only. So anything more complicated that involves
intermediate variables that points to struct or array elements cannot be
solved by TBAA alone. Differentiating
2012 Jan 24
4
[LLVMdev] Pointer aliasing
Can you explain please why it works for this version of the function:
double f(double *__restrict__ x, double *__restrict__ y, double
*__restrict__ z);
What is different here? There are stores here as well.
Brent
On Wed, Jan 25, 2012 at 12:34 AM, Roel Jordans <r.jordans at tue.nl> wrote:
> Hi Brent,
>
> I think this is a problem in the easy-cse transform. In this transform
2016 Jul 26
2
Alias Analysis with inbound GEPs
----- Original Message -----
> From: "Elena Demikhovsky" <elena.demikhovsky at intel.com>
> To: "Hal J. Finkel" <hfinkel at anl.gov>, "Eli Friedman"
> <eli.friedman at gmail.com>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Richard Smith"
> <richard-llvm at metafoo.co.uk>
> Sent: Tuesday, July 26,
2015 Dec 07
3
Field sensitive alias analysis?
BTW, I have found why it doesn't work for arrays. TBAA information
propagation is not implemented in CodeGenFunction::EmitArraySubscriptExpr
with "TODO: Preserve/extend path TBAA metadata?".
On Fri, Dec 4, 2015 at 1:38 PM, Dmitry Polukhin <dmitry.polukhin at gmail.com>
wrote:
> As far as I can see it is specifics of arrays inside structs. Current TBAA
> does distinguish
2012 Jan 24
0
[LLVMdev] Pointer aliasing
Hi Brent,
Looking at your code I can see at least one reason why some of the store
operations remain in the output since you are (through x, y, and z)
writing in memory which exists outside of your function (p).
Constant propagation also seems to work in the first few lines, *y = *x
+1 (%3) is stored directly.
The strange thing to me is that the same doesn't happen for *z = *x + 2.
Here
2015 Jan 23
2
[LLVMdev] question about enabling cfl-aa and collecting a57 numbers
Without the patch is also returns the wrong answer for all of these, it
just doesn't cause LICM to promote because it returns PartialAlias (which
is still wrong).
We return may-alias instead, and now suddenly it's happy to promote them.
The broken noalias results exist both before and after my patch:
===== Alias Analysis Evaluator Report =====
521 Total Alias Queries Performed
2012 Jan 24
0
[LLVMdev] Pointer aliasing
Hi Brent,
I think this is a problem in the easy-cse transform. In this transform
load operations can be replaced by their subexpression, in this case the
propagated constant, based on the value of the 'CurrentGeneration' of
memory writes. This implies that any store operation invalidates the
knowledge about previously stored subexpressions.
In general, this is a safe assumption but
2012 Jan 24
0
[LLVMdev] Pointer aliasing
I have no clue, I didn't have time to look into that example yet.
How does the IR (before optimization) differ from the other version?
Roel
On 01/24/2012 04:45 PM, Brent Walker wrote:
> Can you explain please why it works for this version of the function:
>
> double f(double *__restrict__ x, double *__restrict__ y, double
> *__restrict__ z);
>
> What is different here?
2015 Jan 24
2
[LLVMdev] question about enabling cfl-aa and collecting a57 numbers
No, i mean the actual store instruction looks like "store i16 %conv22, i16*
getelementptr inbounds ([16 x i16]* @pA, i64 0, i64 12), align 2, !tbaa !1"
Not that the pointer operand comes from a GEP, but it is a constantexpr,
whose opcode is GEP.
It sucks that there is such a complex thing to be handled as a store
operand directly , but such is life ...
CFL-AA *should* treat this
2013 Feb 07
1
[LLVMdev] alloca scalarization with dynamic indexing into vectors
Hi all,
I have a question regarding dynamic indexing into a vector with GEP. I see
that in the ScalarReplAggregates pass in the LLVM 3.2 release the call
SROA::isSafeGEP() will now allow alloca scalarization in the case where a
GEP index into a vector isn’t a constant. My question is: what is the
expected behavior when the index is out of bounds of the vector? Is it
undefined? I have an
2012 Jan 24
0
[LLVMdev] Pointer aliasing
Peter Cooper wrote:
> I think the problem here is that the IR doesn't have any way to attach restrict information to loads/stores/pointers.
I think we do now, actually. Now that the loads and stores have TBAA
metadata, I think the restrict attribute can go there. It needs to be
attached to every use of a restrict pointer, but that's similar to how
TBAA already works.
> It works
2017 Feb 13
2
RFC: Representing unions in TBAA
Hello all,
I'm new to the llvm community. I'm learning how things work. I noticed
that there has been some interest in improving how unions are handled. Bug
21725 is one example. I figured it might be a interesting place to start.
I discussed this with a couple people, and below is a suggestion on how
to represent unions. I would like some comments on how this fits in with
how
2019 Nov 15
2
TBAA question
What are you querying the alias analysis on in the above example - between
the load and store?
How are you creating your MemoryLocation for those too?
On Fri, Nov 15, 2019 at 6:03 AM Venkataramanan Kumar via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Can someone please clarify me on this?
>
>
>
> On Wed, 13 Nov 2019 at 22:25, Venkataramanan Kumar <
>
2019 Jun 05
2
llvm-ir: TBAA and struct copies
Hi Ivan,
The code that we have is indeed different from what the 'standard llvm' expects. Let me explain:
in our version we came into this situation in two steps:
1) I added support for 'special types' that map directly to types supported by hardware.
These types are represented by a struct containing a single iXXX member, providing the necessary bits
of the type, and at the
2019 Jun 04
2
llvm-ir: TBAA and struct copies
Hi,
I have a question about the current definition of TBAA (See [1]).
In the LLVM-IR code that we produce, we generate load/stores of struct types. (See [2] and [3] for a godbolt example showing the issue)
For following c-alike code:
struct S { int dummy; short e, f; } x,y;
struct S* p = &x;
int foobar() {
x.f=42;
*p=y; //**** struct copy
return x.f;
}
We produce: