Displaying 7 results from an estimated 7 matches for "gvnexpression".
2017 Sep 22
0
[RFC] PT.2 Add IR level interprocedural outliner for code size.
...however, semantically equivalent
> because they both perform the add operation.
>
> This can be seen by simply removing the operand values used in the
> calculations:
>
> %1 = add i32 , i32
>
> %2 = add i32 , i32
>
>
> FWIW, you could use the core NewGVN structures (GVNExpression.h) to do
this and just not fill in the operands.
GVNSink does a variant of this by using them.
In particular, the variant it does is: "do these instructions contribute to
their uses in an equivalent way". This is the same problem, but if you
weren't going to be willing to add any fun...
2017 Apr 05
2
[NewGVN] Plan for GVNPRE?
Hi Daniel,
Got it. If that's the case, can I implement it under the guidance of your insights/prototype? I think I can spend more time on implementation.
Thanks,
Taewook
________________________________
From: Daniel Berlin <dberlin at dberlin.org>
Sent: Tuesday, April 4, 2017 9:41:30 PM
To: Taewook Oh
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] [NewGVN] Plan for GVNPRE?
Of
2017 Apr 28
3
Store unswitch
Hi Danny,
Thanks for that :) However I've just updated the prototype patch to NewGVN
and it didn't need any API changes - all I rely on is GVNExpression.
Hongbin,
I wanted to explain a little about what GVNSink can currently do, what it
was designed for and hopefully how to make it handle your testcase.
*Background*
Common code sinking is more difficult to efficently do than one might
expect. Prior to October 2016, LLVM was able to handle simpl...
2017 Apr 26
2
Store unswitch
It's basically ready to commit; the reviewers were fairly happy with it. It
needs rebasing on top of NewGVN and any bugs that shakes out fixed, but
that's about it.
I want to get around to it soon-ish, but I've wanted that for a while!
On Wed, 26 Apr 2017 at 16:50, Hongbin Zheng <etherzhhb at gmail.com> wrote:
> Hi James,
>
> I have an ad-hoc solution in mind to solve
2017 Sep 05
5
[RFC] PT.2 Add IR level interprocedural outliner for code size.
Hey Everybody,
A little while ago I posted an RFC(
http://lists.llvm.org/pipermail/llvm-dev/2017-July/115666.html) with the
proposition of adding a new outliner at the IR level. There was some
confusion and many questions regarding the proposal which I’d like to
address here:
Note about nomenclature:
Candidate: A repeated sequence of instructions within a module.
Occurrence: One instance
2017 Sep 17
2
assertion triggered since update to llvm 5
...t<llvm::Value*, 2u> > >&, llvm::Value* const&)
(NewGVN.cpp:1930)
==4585== by 0x4B5DB66: (anonymous
namespace)::NewGVN::markUsersTouched(llvm::Value*)
(NewGVN.cpp:1946)
==4585== by 0x4B5F2F0: (anonymous namespace)::NewGVN::
performCongruenceFinding(llvm::Instruction*, llvm::GVNExpression::Expression
const*) (NewGVN.cpp:2269)
The test case that triggers the assertion yields IR that clang from the
same build can compile without hitting the assertion. I don't think an IR
test case to trigger this necessarily exists.
What path would I go down to come up with this IR?
On Sun, S...
2017 Sep 17
4
assertion triggered since update to llvm 5
So, 90% of the time I've seen this, it was memory corruption, usually use
after free. I know I fixed one after 5.0 branched.
You should compile with address sanitizer enabled, and I suspect you will
find the issue quicky.
If not, we really need ir that reproduces it.
On Sun, Sep 17, 2017, 12:27 PM Andrew Kelley via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I think I forgot to