<feed xmlns='http://www.w3.org/2005/Atom'>
<title>bcm5719-llvm/llvm/test/Transforms/LoopRotate, branch meklort-10.0.1</title>
<subtitle>Project Ortega BCM5719 LLVM</subtitle>
<id>https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1</id>
<link rel='self' href='https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/'/>
<updated>2020-01-11T10:03:29+00:00</updated>
<entry>
<title>[LoopRotate] Add tests for rotate with switch; NFC</title>
<updated>2020-01-11T10:03:29+00:00</updated>
<author>
<name>Nikita Popov</name>
<email>nikita.ppv@gmail.com</email>
</author>
<published>2020-01-09T21:17:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=142ba7d76af4a66037fd180db371da19f35ef5f3'/>
<id>urn:sha1:142ba7d76af4a66037fd180db371da19f35ef5f3</id>
<content type='text'>
For D72420.
</content>
</entry>
<entry>
<title>[BasicBlockUtils] Fix dbg.value elimination problem in MergeBlockIntoPredecessor</title>
<updated>2019-12-16T10:41:21+00:00</updated>
<author>
<name>Bjorn Pettersson</name>
<email>bjorn.a.pettersson@ericsson.com</email>
</author>
<published>2019-12-13T14:53:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=e5f07080b8ac73dd573e81a186925a122ab8a39d'/>
<id>urn:sha1:e5f07080b8ac73dd573e81a186925a122ab8a39d</id>
<content type='text'>
Summary:
In commit d60f34c20a2f31335c8d5626e (llvm-svn 317128,
PR35113) MergeBlockIntoPredecessor was changed into
discarding some dbg.value intrinsics referring to
PHI values, post-splice due to loop rotation.

That elimination of dbg.value intrinsics did not
consider which dbg.value to keep depending on the
context (e.g. if the variable is changing its value
several times inside the basic block).

In the past that hasn't been such a big problem since
CodeGenPrepare::placeDbgValues has moved the dbg.value
to be next to the PHI node anyway. But after commit
00e238896cd8ad3a7d7 CodeGenPrepare isn't doing that
any longer, so we need to be more careful when avoiding
duplicate dbg.value intrinsics in MergeBlockIntoPredecessor.

This patch replaces the code that tried to avoid duplicate
dbg.values by using the RemoveRedundantDbgInstrs helper.

Reviewers: aprantl, jmorse, vsk

Reviewed By: aprantl, vsk

Subscribers: jholewinski, hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D71480
</content>
</entry>
<entry>
<title>[LoopRotate] Add test case to show dbg value problem</title>
<updated>2019-12-16T10:41:21+00:00</updated>
<author>
<name>Bjorn Pettersson</name>
<email>bjorn.a.pettersson@ericsson.com</email>
</author>
<published>2019-12-13T14:44:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=632deb6bd04022945468faef2dcaa8c9fdf1b0fd'/>
<id>urn:sha1:632deb6bd04022945468faef2dcaa8c9fdf1b0fd</id>
<content type='text'>
Summary:
In commit d60f34c20a2f31335c8d5626e (llvm-svn 317128,
PR35113) MergeBlockIntoPredecessor was changed into
discarding some dbg.value intrinsics referring to
PHI values, post-splice due to loop rotation.

That elimination of dbg.value intrinsics does not
consider which dbg.value to keep based on the context.
Such as always keeping the one that comes first textually,
or the need to keep several of them in case the variable
is changing it's value several times inside the basic block.

In the past that hasn't been such a big problem since
CodeGenPrepare::placeDbgValues has moved the dbg.value
to be next to the PHI node anyway. But after commit
00e238896cd8ad3a7d7 CodeGenPrepare isn't doing that
any longer, so we need to be more careful when avoiding
duplicate dbg.value intrinsics in MergeBlockIntoPredecessor.

This patch is just a pre commit of the test case.

Subscribers: llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D71479
</content>
</entry>
<entry>
<title>[LoopPassManager + MemorySSA] Only enable use of MemorySSA for LPMs known to preserve it.</title>
<updated>2019-08-21T17:00:57+00:00</updated>
<author>
<name>Alina Sbirlea</name>
<email>asbirlea@google.com</email>
</author>
<published>2019-08-21T17:00:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=7425179fee9b4ed1ff6d366ee06487f05a1c0ab3'/>
<id>urn:sha1:7425179fee9b4ed1ff6d366ee06487f05a1c0ab3</id>
<content type='text'>
Summary:
Add a flag to the FunctionToLoopAdaptor that allows enabling MemorySSA only for the loop pass managers that are known to preserve it.

If an LPM is known to have only loop transforms that *all* preserve MemorySSA, then use MemorySSA if `EnableMSSALoopDependency` is set.
If an LPM has loop passes that do not preserve MemorySSA, then the flag passed is `false`, regardless of the value of `EnableMSSALoopDependency`.

When using a custom loop pass pipeline via `passes=...`, use keyword `loop` vs `loop-mssa` to use MemorySSA in that LPM. If a loop that does not preserve MemorySSA is added while using the `loop-mssa` keyword, that's an error.

Add the new `loop-mssa` keyword to a few tests where a difference occurs when enabling MemorySSA.

Reviewers: chandlerc

Subscribers: mehdi_amini, Prazek, george.burgess.iv, sanjoy.google, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D66376

llvm-svn: 369548
</content>
</entry>
<entry>
<title>Revert "Temporarily Revert "Add basic loop fusion pass.""</title>
<updated>2019-04-17T04:52:47+00:00</updated>
<author>
<name>Eric Christopher</name>
<email>echristo@gmail.com</email>
</author>
<published>2019-04-17T04:52:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=cee313d288a4faf0355d76fb6e0e927e211d08a5'/>
<id>urn:sha1:cee313d288a4faf0355d76fb6e0e927e211d08a5</id>
<content type='text'>
The reversion apparently deleted the test/Transforms directory.

Will be re-reverting again.

llvm-svn: 358552
</content>
</entry>
<entry>
<title>Temporarily Revert "Add basic loop fusion pass."</title>
<updated>2019-04-17T02:12:23+00:00</updated>
<author>
<name>Eric Christopher</name>
<email>echristo@gmail.com</email>
</author>
<published>2019-04-17T02:12:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=a86343512845c9c1fdbac865fea88aa5fce7142a'/>
<id>urn:sha1:a86343512845c9c1fdbac865fea88aa5fce7142a</id>
<content type='text'>
As it's causing some bot failures (and per request from kbarton).

This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda.

llvm-svn: 358546
</content>
</entry>
<entry>
<title>[LoopRotate] fix crash encountered with callbr</title>
<updated>2019-03-06T23:04:40+00:00</updated>
<author>
<name>Nick Desaulniers</name>
<email>ndesaulniers@google.com</email>
</author>
<published>2019-03-06T23:04:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=212c8ac23f4f3313c847eb42cac1088cc4c3d39f'/>
<id>urn:sha1:212c8ac23f4f3313c847eb42cac1088cc4c3d39f</id>
<content type='text'>
Summary:
While implementing inlining support for callbr
(https://bugs.llvm.org/show_bug.cgi?id=40722), I hit a crash in Loop
Rotation when trying to build the entire x86 Linux kernel
(drivers/char/random.c). This is a small fix up to r353563.

Test case is drivers/char/random.c (with callbr's inlined), then ran
through creduce, then `opt -opt-bisect-limit=&lt;limit&gt;`, then bugpoint.

Thanks to Craig Topper for immediately spotting the fix, and teaching me
how to fish.

Reviewers: craig.topper, jyknight

Reviewed By: craig.topper

Subscribers: hiraditya, llvm-commits, srhines

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D58929

llvm-svn: 355564
</content>
</entry>
<entry>
<title>Remove irrelevant references to legacy git repositories from</title>
<updated>2019-01-15T16:18:52+00:00</updated>
<author>
<name>James Y Knight</name>
<email>jyknight@google.com</email>
</author>
<published>2019-01-15T16:18:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=693d39dd12710a3634e287dfa5d0dd516fbe24d6'/>
<id>urn:sha1:693d39dd12710a3634e287dfa5d0dd516fbe24d6</id>
<content type='text'>
compiler identification lines in test-cases.

(Doing so only because it's then easier to search for references which
are actually important and need fixing.)

llvm-svn: 351200
</content>
</entry>
<entry>
<title>Update MemorySSA in LoopRotate.</title>
<updated>2018-10-24T22:46:45+00:00</updated>
<author>
<name>Alina Sbirlea</name>
<email>asbirlea@google.com</email>
</author>
<published>2018-10-24T22:46:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=ad4d018202d7f967c56b6adcfc283f7273b9d356'/>
<id>urn:sha1:ad4d018202d7f967c56b6adcfc283f7273b9d356</id>
<content type='text'>
Summary:
Teach LoopRotate to preserve MemorySSA.
Enable tests for correctness, dependency disabled by default.

Subscribers: sanjoy, jlebar, Prazek, george.burgess.iv, llvm-commits

Differential Revision: https://reviews.llvm.org/D51718

llvm-svn: 345216
</content>
</entry>
<entry>
<title>[New PM] Introducing PassInstrumentation framework</title>
<updated>2018-09-20T17:08:45+00:00</updated>
<author>
<name>Fedor Sergeev</name>
<email>fedor.sergeev@azul.com</email>
</author>
<published>2018-09-20T17:08:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=ee8d31c49e12a4d1fc10940a8fa644e5351239ed'/>
<id>urn:sha1:ee8d31c49e12a4d1fc10940a8fa644e5351239ed</id>
<content type='text'>
Pass Execution Instrumentation interface enables customizable instrumentation
of pass execution, as per "RFC: Pass Execution Instrumentation interface"
posted 06/07/2018 on llvm-dev@

The intent is to provide a common machinery to implement all
the pass-execution-debugging features like print-before/after,
opt-bisect, time-passes etc.

Here we get a basic implementation consisting of:
* PassInstrumentationCallbacks class that handles registration of callbacks
  and access to them.

* PassInstrumentation class that handles instrumentation-point interfaces
  that call into PassInstrumentationCallbacks.

* Callbacks accept StringRef which is just a name of the Pass right now.
  There were some ideas to pass an opaque wrapper for the pointer to pass instance,
  however it appears that pointer does not actually identify the instance
  (adaptors and managers might have the same address with the pass they govern).
  Hence it was decided to go simple for now and then later decide on what the proper
  mental model of identifying a "pass in a phase of pipeline" is.

* Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies
  on different IRUnits (e.g. Analyses).

* PassInstrumentationAnalysis analysis is explicitly requested from PassManager through
  usual AnalysisManager::getResult. All pass managers were updated to run that
  to get PassInstrumentation object for instrumentation calls.

* Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra
  args out of a generic PassManager's extra args. This is the only way I was able to explicitly
  run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or
  RepeatedPass::run.
  TODO: Upon lengthy discussions we agreed to accept this as an initial implementation
  and then get rid of getAnalysisResult by improving RepeatedPass implementation.

* PassBuilder takes PassInstrumentationCallbacks object to pass it further into
  PassInstrumentationAnalysis. Callbacks registration should be performed directly
  through PassInstrumentationCallbacks.

* new-pm tests updated to account for PassInstrumentationAnalysis being run

* Added PassInstrumentation tests to PassBuilderCallbacks unit tests.
  Other unit tests updated with registration of the now-required PassInstrumentationAnalysis.

  Made getName helper to return std::string (instead of StringRef initially) to fix
  asan builtbot failures on CGSCC tests.

Reviewers: chandlerc, philip.pfaffe
Differential Revision: https://reviews.llvm.org/D47858

llvm-svn: 342664
</content>
</entry>
</feed>
