Displaying 20 results from an estimated 1000 matches similar to: "[MemorySSA] inserting or removing memory instructions"
2017 Feb 17
2
[MemorySSA] inserting or removing memory instructions
In particular, if you want to add support, the right way to know what to
rename is (off the top of my head)
add a flag or something to have renamepass reset all uses it sees (you only
have to change the uses, defs are all linked together and thus already
fixed by the updater). Right now it only does that if they have no
defining access.
Make it skip blocks already in the visited set (the
2018 Aug 09
2
llvm MemorySSA def-use chains
Hi,
I have a question about how llvm MemorySSA works, as seems I misunderstand something.
Consider following code snippet and corresponding IR with MemorySSA annotations (got with opt -print-memoryssa)
void foo(int* b) {
int a = 0;
int d = 12;
if (b) {
a = 42;
d = 32;
}
int c = a;
int e = d;
}
; Function Attrs: noinline nounwind optnone uwtable
2017 Dec 19
4
MemorySSA question
Hi,
I am new to MemorySSA and wanted to understand its capabilities. Hence I
wrote the following program (test.c):
int N;
void test(int *restrict a, int *restrict b, int *restrict c, int *restrict
d, int *restrict e) {
int i;
for (i = 0; i < N; i = i + 5) {
a[i] = b[i] + c[i];
}
for (i = 0; i < N - 5; i = i + 5) {
e[i] = a[i] * d[i];
}
}
I compiled this program using
2018 Aug 10
2
llvm MemorySSA def-use chains
Hi,
try adding some alias analysis to the pipeline: see examples in
llvm/test/Analysis/MemorySSA/*.ll
for example assume.ll has
; RUN: opt -aa-pipeline=basic-aa -passes='print<memoryssa>,verify<memoryssa>'
without basic-aa the memory ssa will safely assume that the stores to
%a and %d alias which may be proven disjoint by one of the alias
analyses.
On Thu, Aug 9, 2018 at 8:37
2017 Dec 19
2
MemorySSA question
On Tue, Dec 19, 2017 at 9:10 AM, Siddharth Bhat via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I could be entirely wrong, but from my understanding of memorySSA, each
> def defines an "abstract heap state" which has the coarsest possible
> definition - any write will be modelled as a "new heap state".
>
This is true for def-def relationships, but
2016 Apr 29
2
[MemorySSA] Potential CachingMemorySSAWalker bug
Hi guys,
I think I have run into another CachingMemorySSAWalker cache bug. It's
a bit tricky to reproduce, so I'd like to start by trying to show you
what is happening when running EarlyCSE with my local changes to use
MemorySSA. I've attached a debug log that shows that the value returned
by getClobberingMemoryAccess(Inst) after a call to removeMemoryAccess is
wrong. The
2016 May 02
2
[MemorySSA] Potential CachingMemorySSAWalker bug
I suspect something is pulling the RHS of the memorydef and caching it for
calls it should not be used for.
In particular, i suspect we are about to discover we can't cache the
results from both versions of getClobberingMemoryAccess together, or that
the cache is not always getting consistently written.
On Mon, May 2, 2016 at 11:16 AM, George Burgess IV <
george.burgess.iv at
2018 Feb 09
1
PHI nodes for atomic variables
Dear Daniel Berlin,
I just tried MemorySSA analysis and get the next IR.
However, I feel confused by the result.
Specifically, why instruction *%3* relates to a *MemoryDef*. According to
my understanding,
I think *%3* should be related to a *MemoryUse*, right?
; Function Attrs: uwtable
define void @_Z2f1v() #3 personality i32 (...)* @__gxx_personality_v0 {
entry:
; 1 = MemoryDef(liveOnEntry)
2016 May 02
2
[MemorySSA] Potential CachingMemorySSAWalker bug
I've put my changes to EarlyCSE that trigger this case up on phab here:
http://reviews.llvm.org/D19821. These changes depend on
http://reviews.llvm.org/D19664 so that will need to be applied first.
With these changes applied, the original attached .ll file should
trigger this bug when compiled with opt -early-cse -early-cse-use-memoryssa
On 5/2/2016 2:34 PM, Daniel Berlin wrote:
>
2016 Jun 27
2
[MemorySSA] Potential bug in MemoryUse defining access calculation
Hey All,
I've come across what I believe to be a bug in MemorySSA. George, I
wasn't sure if this was a known issue that you'll be addressing in your
upcoming walker caching changes or not, so I haven't investigated it
very much. The test case is attached. The bug is that the defining
access for the second load is set to the loop MemoryPhi node instead of
being liveOnEntry as
2015 Apr 28
2
[LLVMdev] alias set collapse and LICM
On Mon, Apr 27, 2015 at 4:21 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
> You can't win here (believe me, i've tried, and better people than me have
> tried, for years :P).
> No matter what you do, the partitioning will never be 100% precise. The
> only way to solve that in general is to pairwise query over the
> partitioning.
>
> Your basic problem is
2018 Feb 08
0
PHI nodes for atomic variables
Let me try to help.
On Thu, Feb 8, 2018 at 12:13 PM, Qiuping Yi via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Thanks for your explanation.
>
> Do you mean that LLVM will not maintain the def-use chain for atomic
> variables?
>
It is not a variable at the LLVM level.
At the source level, it is a variable.
At the LLVM IR level, it is lowered into memory operations.
All
2017 Sep 23
2
Potential infinite loop in MemorySSAUpdater
With regards
Bhargav Reddy Godala
Software Engineer 2
Bangalore, India
E-mail: Bhargav-reddy.Godala at amd.com<mailto:Bhargav-reddy.Godala at amd.com> Ext 30678
On 23-Sep-2017, at 9:27 PM, Daniel Berlin <dberlin at dberlin.org<mailto:dberlin at dberlin.org>> wrote:
On Sat, Sep 23, 2017 at 8:38 AM, Godala, Bhargav-reddy via llvm-dev <llvm-dev at
2018 Feb 08
3
PHI nodes for atomic variables
Thanks for your explanation.
Do you mean that LLVM will not maintain the def-use chain for atomic
variables?
So it is impossible to directly catch the fact that the load of x at the
statement 'data1 = x; ' dependents on data4 (because of the statement
x=data4 )?
If I want to get such information, may be the only solution is to traverse
all the predecessors of the statement 'data1 =
2017 Dec 21
4
Hoisting in the presence of volatile loads.
On 12/20/2017 03:49 PM, Alina Sbirlea via llvm-dev wrote:
> +Philip to get his input too.
> I've talked with George offline, and here's a summary:
>
> In D16875 <https://reviews.llvm.org/D16875>, the decision made was:
> "The LLVM spec is ambiguous about whether we can hoist a non-volatile
> load above a volatile load when the loads alias. It's probably
2017 Sep 25
2
Potential infinite loop in MemorySSAUpdater
I understand that changing the starting element to “InsertedPHIs.being() + StartingPHISize” it will be finite but given that InsrtedPHIs is finite.
I have a case where one element(same element is appened to InsertedPHIs) is added to InsertedPHIs every time fixupDefs is invoked. I traced the issue why this was happening.
template <class RangeType>
MemoryAccess
2017 Sep 23
0
Potential infinite loop in MemorySSAUpdater
On Sat, Sep 23, 2017 at 9:55 AM, Godala, Bhargav-reddy <
Bhargav-reddy.Godala at amd.com> wrote:
>
> With regards
> Bhargav Reddy Godala
> Software Engineer 2
> Bangalore, India
> E-mail: Bhargav-reddy.Godala at amd.com Ext 30678
>
>
>
> On 23-Sep-2017, at 9:27 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
>
>
> On Sat, Sep 23, 2017 at
2016 Oct 30
0
[PATCH] D26127: [MemorySSA] Repair AccessList invariants after insertion of new MemoryUseOrDef.
On Sun, Oct 30, 2016 at 4:08 PM, Bryant Wong <
3.14472+reviews.llvm.org at gmail.com> wrote:
>
> On Sun, Oct 30, 2016 at 6:48 PM, Daniel Berlin <dberlin at dberlin.org>
> wrote:
>
>> In particular:
>> "
>> I'm not so sure that it's sufficient. Suppose, for instance, that I
>> wanted to insert a MemoryDef between 1 and 2 in the below
2017 Sep 23
2
Potential infinite loop in MemorySSAUpdater
Hi,
Can some one explain the intended behaviour of following loop in void MemorySSAUpdater::insertDef(MemoryDef *MD, bool RenameUses) function.
while (!FixupList.empty()) {
unsigned StartingPHISize = InsertedPHIs.size();
fixupDefs(FixupList);
FixupList.clear();
// Put any new phis on the fixup list, and process them
FixupList.append(InsertedPHIs.end() - StartingPHISize,
2016 Jun 27
0
[MemorySSA] Potential bug in MemoryUse defining access calculation
This is definitely a caching bug related to this code:
1038 // Don't try to optimize this phi again if we've already tried
to do so.
1039 if (!Q.Visited.insert(PHIPair).second) {
1040 ModifyingAccess = CurrAccess;
1041 break;
1042 }
We don't differentiate elsewhere between having stopped at a phi because we
were path walking and discovered that path