- User Since
- Feb 10 2017, 1:36 AM (96 w, 4 d)
Wed, Dec 12
Tue, Dec 11
Not really. If you say have a Loop* pointer, which is freed and then another Loop allocated happens to be just at that pointer
then you dont have a way to identify whether it is the old Loop or the new one.
Presumably that does not happen now...
Mon, Dec 10
Invalid handle might be totally invalid, you can not use it for anything.
I do remember having accesses to freed memory when accessing either Loop or SCC, dont remember which one.
Even looking at the address might be not that sane if it was freed and perhaps something else allocated at that place.
Fri, Dec 7
removing unneeded asserts
So, whats the plan here?
ElfYamlTextAPI.YAMLWritesNoTBESyms continues to fail in my local builds with LLVM_LINK_LLVM_DYLIB...
Thu, Dec 6
updated the summary.
Wed, Dec 5
- Make a free function for creating the global constructor function
- The opt tool calls this function when passing a command line option
What is the benefit of having free function compared to having a module-level pass that does the same?
Tue, Dec 4
stack handling fixed (AfterPass now pops stack as well)
oops, this needs a small update
slight cleanup in anticipation of a followup that handles invalidated printing
Mon, Dec 3
Up to this point it kinda makes sense.
However, this suggestion of storing supplementary passes information into the IR itself does not sound like a good design decision.
A typical solution for LLVM to store supporting information is to introduce an Analysis, so it kinda floats around the IR, but
is not being stored directly into it.
Btw, @markus, you can go push this thing.
Sun, Dec 2
The tests are trying to count loops at different depths, using -COUNT-<NUM> directives, e.g. 11 loops at depth 1, 40 loops at depth 2.
Alternative to sorting would be to implement support for -COUNT-<NUM>-DAG.
Fri, Nov 30
Thu, Nov 29
Mon, Nov 26
Reverted by rL347541 due to P39774 mentioned above.
It is very likely that this change is not a direct cause of the crash,
but I dont know any other ways to get rid of that crash.
Sun, Nov 25
This fix appears to cause bugs.llvm.org/show_bug.cgi?id=39774
Thu, Nov 22
Wed, Nov 21
Eventually we should implement error checking for new-pm pass names.
That will require adding more new-pm related code to the parser, and introduce some
kind of an interface with PassBuilder. Definitely *not* planned for this patch.
The goal is to use the same -print-after *option* to control this functionality in newpm, and not just reimplement it with a different control.
return value for Scalarizer::run fixed in rL347432
Ugh... thanks for noting this, no idea how I managed to miss that during review.
Will patch it myself.
Ah, sure, thanks!
Looks ok, feel free to push. Thanks!
You can use explicit qualification here:
bool Done = InstVisitor::visit(I);
Tue, Nov 20
adding new instrumentation point to unittests
LGTM, but feel free to address Chandlers' note if you dont have strong feelings against it.
Looks nearly ready to go.
moved "invalidated after-pass" into its own callback, looks like a proper solution, indeed.
Overall it looks really good!
Mon, Nov 19
scc-deleted-printer test updated
oops... scc-deleted-printer.ll is not yet ready - skip it until updated.
everything else should be fine.
The test introduced here seems to be invalid.
It assumes that 16*128 attempts to choose a random hex number will cover all 16 available numbers.
Obviously, the chance for this test to fail is rather low but it is not 0.
To me it would be a cleaner solution if you could split legacy FunctionPass interface implementation into a separate wrapper pass (e.g. ScalarizerLegacyPass),
similar to how new-pm wrapper ScalarizerPass implements all the new-pm interfaces.
That would allow to separate actual transformation (Scalarizer) from pass-manager details (ScalarizerPass/ScalarizerLegacyPass).
Nov 16 2018
Nov 14 2018
getting clones calculation more precise
updating names, comments etc
handle switch candidates; exponential switch case added
Discovered a tricky testcase with 16-way switch and nested exiting branches which manages to skip the multiplier introduced here and still lead to exponential explosion.
Definitely need to check if exiting branch dominates the latch before skipping its multiplier calculation.
Also the testcase shows that we really need to go further calculating costs per candidate and using that in calculation of exponential-explosion threshold, just as Chandler asked to.
Nov 12 2018
renamed bottom-cap option, updated comments, tests
more extensive checking for exiting branches; adding tests with exiting branches
update as per Max' comments
Nov 11 2018
Nov 10 2018
Hmm... can you point me where function definitions are being added in doInitialization, I just dont see it (frankly I'm not familiar with this code at all).
Makes sense to mention this in commit message...
I assume the main problem with this being function pass in NewPM is the need for initialization, which is too slow when being done per-function.
LGTM (though I have no idea what legacy does for this :) )
Nov 9 2018
addressing comments, clang-formatted, added std includes, some minor stuff
I know, it needs documentation changes :)