Displaying 7 results from an estimated 7 matches for "whilebodi".
Did you mean:
whilebody
2008 Oct 01
2
[LLVMdev] complex branching generation
LLVM seems to be generating way too complex of branching based on the
short-circuit optimization. The code in question is as follows:
define void @ test_fc_while_and(float %x, float %y, float addrspace(11)*
%result) nounwind {
entry:
%tobool3 = fcmp une float %x, 0.000000e+000 ; <i1>
[#uses=1]
%tobool24 = fcmp une float %y, 0.000000e+000 ;
2008 Oct 01
0
[LLVMdev] complex branching generation
On Wed, Oct 1, 2008 at 1:19 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
> LLVM seems to be generating way too complex of branching based on the
> short-circuit optimization. The code in question is as follows:
>
> define void @ test_fc_while_and(float %x, float %y, float addrspace(11)*
> %result) nounwind {
>
> entry:
>
> %tobool3 = fcmp une float
2010 Jan 28
2
[LLVMdev] llc generated machine assembly code for NASM
Hello,
I am new here. This is my first post.
I spent about three days on trying out LLVM by developing a front-end which
is able to generate LLVM IR for a subset of C language. I have not applied
any optimization pass yet. On linux, it can go all the way through with the
system native assemlber and linker to generate executables. And it runs. I
ran into problems on Windows since the generated
2017 Sep 16
2
assertion triggered since update to llvm 5
When zig updated to llvm 5 we started hitting this assertion:
zig:
/home/andy/downloads/llvm-project/llvm/include/llvm/Support/Casting.h:106:
static bool llvm::isa_impl_cl<To, const From*>::doit(const From*) [with To
= llvm::Instruction; From = llvm::Value]: Assertion `Val && "isa<> used on
a null pointer"' failed.
I wonder if however this was caused by an
2017 Sep 17
2
assertion triggered since update to llvm 5
Can you please open a bug on bugzilla and attach the ir testcase? Your fix
doesn't look right (just hiding the assertion failure)
On Sep 17, 2017 10:45 AM, "Andrew Kelley via llvm-dev" <
llvm-dev at lists.llvm.org> wrote:
> What do you think about this patch?
>
> --- a/llvm/lib/Transforms/Scalar/NewGVN.cpp
> +++ b/llvm/lib/Transforms/Scalar/NewGVN.cpp
> @@
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
2017 Sep 17
2
assertion triggered since update to llvm 5
Dump the IR before newgvn and run through opt -newgvn. It should crash. I'm
not familiar with your frontend but you might want to use -mllvm
-opt-bisect-limit.
On Sep 17, 2017 1:06 PM, "Andrew Kelley" <superjoe30 at gmail.com> wrote:
Valgrind is strictly better than address sanitizer, is that right? It runs
valgrind-clean:
[nix-shell:~/dev/zig/build-llvm5-debug]$ valgrind