Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] tbaa differences in llvm 3.0"
2012 Jan 28
0
[LLVMdev] tbaa differences in llvm 3.0
On Jan 27, 2012, at 4:15 PM, Maurice Marks wrote:
> Our application generates IR that is used to generate X86_64 code for a Jit. We noticed that code generated with llvm 3.0 is worse in some circumstances that it was with 2.9. I traced the differences to alias analysis differences. Our IR references data structures that have lots of derived pointers and we use extensive tbaa metadata to
2012 Jan 28
2
[LLVMdev] tbaa differences in llvm 3.0
Many of our pointers point into a structure where they could be considered
as having the same base address. We use tbaa to indicate which ones could
or could not alias because they are pointing into different substructures.
This is exactly the sort of requirement that invoked the need for the
restrict modifier in g++, c++0x etc. If I understand you correctly that
cannot be expressed in llvm ir
2012 Jan 31
3
[LLVMdev] tbaa differences in llvm 3.0
On Fri, 2012-01-27 at 16:46 -0800, Dan Gohman wrote:
> On Jan 27, 2012, at 4:15 PM, Maurice Marks wrote:
>
> > Our application generates IR that is used to generate X86_64 code for a Jit. We noticed that code generated with llvm 3.0 is worse in some circumstances that it was with 2.9. I traced the differences to alias analysis differences. Our IR references data structures that have
2012 Jan 30
0
[LLVMdev] tbaa differences in llvm 3.0
In our case basicaa alone returns "may alias" on our pointers and we want
to override that with tbaa data to "Wont alias" when we know that the
pointers will never alias. So its not covered by your case.
Since the basicaa pass doesnt chain according to the llvm docs, it should
have the last chance to affect the aliasing information, and that means it
should be added first. If
2017 May 11
3
Alias analysis results
Hello,
I'm trying to get the whole picture of what we are doing in terms
of alias analysis in LLVM. Being new to this I may be missing
some well known things so my apologies if I seem to ask obvious
things.
There are lots of questions arise in my head as I read related
bug reports, sources and documentation, of which looks to be the
most simple is,
Why the current TBAA implementation
2015 Jan 16
3
[LLVMdev] Alias Analysis pass ordering in LLVM (and Clang)
(sorry for the wide distribution, but this impacts Clang users quite a bit)
It's come up a few times in reviews of CFL-AA (a new alias analysis for
LLVM), so I wanted to write down what I think the current state actually is
for AA pass ordering, why, and how it should look eventually. I may have
some bugs here, so please correct me if I miss anything. And I'd love
thoughts about the end
2012 Nov 09
3
[LLVMdev] inttoptr and basicaa
Hi,
I am observing some incorrect behavior in basicaa, wherein two pointers that
basicaa should determine to be MustAlias are ending up NoAlias - the other
extreme :(
I am blaming this on basicaa not handling inttoptr. Here is the relevant IR
snippet.
--------------------
%sunkaddr36 = ptrtoint %struct.BitParams* %bs to i32
%sunkaddr37 = add i32 %sunkaddr36, 16
%sunkaddr38 = inttoptr i32
2012 Nov 09
0
[LLVMdev] inttoptr and basicaa
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Arnold Schwaighofer
> Subject: [LLVMdev] inttoptr and basicaa
> BasicAA treats it conservatively if used on its own. It will return mayalias
> for the two pointers.
> TBAA operates based on the guarantee that pointers to different types cannot
> alias (think C's strict
2012 Nov 09
2
[LLVMdev] inttoptr and basicaa
BasicAA treats it conservatively if used on its own. It will return
mayalias for the two pointers.
TBAA operates based on the guarantee that pointers to different types
cannot alias (think C's strict aliasing rules).
Therein lies its power but also its danger, that is, nothing prevents the
programmer to write code that violates these rules (That's why we have
-fno-strict-aliasing).
So
2013 Mar 27
1
[LLVMdev] PROPOSAL: struct-access-path aware TBAA (new version)
Hello,
After discussions with Daniel, Dan and others, here is an updated proposal for struct-access-path aware TBAA.
Given an example
struct A {
int x;
int y;
};
struct B {
A a;
int z;
};
struct C {
B b1;
B b2;
int *p;
};
struct D {
C c;
};
The purpose of struct-path-aware TBAA is to say
"C::b1.a" will alias with "B::a.x", "C::b1.a" will alias with
2015 Jan 20
4
[LLVMdev] question about enabling cfl-aa and collecting a57 numbers
So, I can make all these testcases work, but it's a little tricky (it
involves tracking some things, like GEP byte range, and then checking bases
and using getObjectSize, much like BasicAA does).
Because i really don't want to put that much "not well tested" code in a
bugfix, and honestly, i'm not sure we will catch any cases here that
BasicAA does not, i've attached a
2015 Jan 14
3
[LLVMdev] question about enabling cfl-aa and collecting a57 numbers
Oh, sorry, i didn't rebase it when i changed the fix, you would have had to
apply the first on top of the second.
Here is one against HEAD
On Wed, Jan 14, 2015 at 12:32 PM, Ana Pazos <apazos at codeaurora.org> wrote:
> Daniel, your patch does not apply cleanly. Are you on the tip?
>
> The code I see there is no line if (QueryResult == MayAlias|| QueryResult == PartialAlias)
2015 Jan 14
2
[LLVMdev] question about enabling cfl-aa and collecting a57 numbers
Can you send me actual LLVM IR or a preprocessed source from using -E?
I don't have a machine handy that has headers that target that arch.
On Tue Jan 13 2015 at 4:33:29 PM Daniel Berlin <dberlin at dberlin.org> wrote:
> Anything other than noalias or mustalias should be getting passed down the
> stack, so either that is not happening or CFL aa is giving better answers
> and
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
2015 Jan 14
4
[LLVMdev] question about enabling cfl-aa and collecting a57 numbers
Inline
- George
> On Jan 14, 2015, at 10:49 AM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
>
>
>> On Tue, Jan 13, 2015 at 11:26 PM, Nick Lewycky <nlewycky at google.com> wrote:
>>> On 13 January 2015 at 22:11, Daniel Berlin <dberlin at dberlin.org> wrote:
>>> This is caused by CFLAA returning PartialAlias for a query that BasicAA can
2015 Jan 15
2
[LLVMdev] question about enabling cfl-aa and collecting a57 numbers
Yes.
I've attached an updated patch that does the following:
1. Fixes the partialalias of globals/arguments
2. Enables partialalias for cases where nothing has been unified to a
global/argument
3. Fixes that select was unifying the condition to the other pieces (the
condition does not need to be processed :P). This was causing unnecessary
aliasing.
4. Adds a regression test to
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
2015 Jan 14
3
[LLVMdev] question about enabling cfl-aa and collecting a57 numbers
On 13 January 2015 at 22:11, Daniel Berlin <dberlin at dberlin.org> wrote:
> This is caused by CFLAA returning PartialAlias for a query that BasicAA
> can prove is NoAlias.
>
One of them is wrong. Which one?
I'm not sure from your description that this is a chaining issue.
PartialAlias doesn't chain and isn't supposed to, it's a final answer just
like NoAlias and
2012 Oct 19
2
[LLVMdev] Choosing an alias analyzer
Hi,
In lib/Transforms/IPO/PassManagerBuilder.cpp: addInitialAliasAnalysisPasses,
I see this code
------
// Add TypeBasedAliasAnalysis before BasicAliasAnalysis so that
// BasicAliasAnalysis wins if they disagree. This is intended to help
// support "obvious" type-punning idioms.
PM.add(createTypeBasedAliasAnalysisPass());
PM.add(createBasicAliasAnalysisPass());
}
------
My
2015 Jan 13
2
[LLVMdev] question about enabling cfl-aa and collecting a57 numbers
Hi folks,
Moving the discussion to llvm.dev.
None of the changes we talked earlier help.
Find attached the C source code that you can use to reproduce the issue.
clang --target=aarch64-linux-gnu -c -mcpu=cortex-a57 -Ofast -fno-math-errno test.c -S -o test.s -mllvm -debug-only=licm
LICM hoisting to while.body.lr.ph: %21 = load double** %arrayidx8, align 8, !tbaa !5
LICM hoisting to