similar to: [LLVMdev] loads from a null address and optimizations

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] loads from a null address and optimizations"

2009 Sep 05
4
[LLVMdev] loads from a null address and optimizations
Hi, I don't intentionally want to induce a tramp, the load null is created by an llvm optimization pass from code like: v = null; ..... v.Call (); Zoltan On Sat, Sep 5, 2009 at 11:39 PM, Bill Wendling <isanbard at gmail.com> wrote: > Hi Zoltan, > > We've come across this before where people meant to induce a trap by > dereferencing a null. It
2009 Sep 05
0
[LLVMdev] loads from a null address and optimizations
Hi Zoltan, We've come across this before where people meant to induce a trap by dereferencing a null. It doesn't work for LLVM (as you found out). Essentially, it's a valid transformation to turn this into unreachable. The better solution is to use something like __builtin_trap. -bw On Sep 5, 2009, at 2:19 PM, Zoltan Varga <vargaz at gmail.com> wrote: > >
2009 Sep 06
0
[LLVMdev] loads from a null address and optimizations
How about this: 1. A custom pass run at the beginning that inserts a null check before every load/store: if ( ptr == null ) trap; Then if any pointers get optimized to null, the if condition becomes a constant true,and the trap call should become unconditional. 2. A custom pass at the end that takes out every remaining null check that your first pass inserted. It should first check whether
2008 Dec 09
3
[LLVMdev] [PATH] Add sub.ovf/mul.ovf intrinsics
Hi, Attached is the final version of the patch, adding the requested FIXME. If this is ok, can somebody check it in ? thanks Zoltan On Tue, Dec 9, 2008 at 9:58 PM, Bill Wendling <isanbard at gmail.com> wrote: > On Tue, Dec 9, 2008 at 6:11 AM, Zoltan Varga <vargaz at gmail.com> wrote: >> Hi, >>
2009 May 04
3
[LLVMdev] [PATH] Fixes for the amd64 JIT code
Hi, If this looks ok, could somebody check it in ? thanks Zoltan Evan Cheng-2 wrote: > > Looks good. Thanks. > > Evan > > On May 1, 2009, at 8:40 AM, Zoltan Varga wrote: > >> Hi, >> >> The attached patch contains the following changes: >> >> * X86InstrInfo.cpp: Synchronize a few places with the code
2008 Dec 09
4
[LLVMdev] [PATH] Add sub.ovf/mul.ovf intrinsics
Hi, Here is the next iteration of the patch. The only comment not addressed is this one: > It would be better to implement a target-independent check for > overflow for the "Legal" case (like how SADDO does). Hacker's > Delight > has some hints on how to do this. It's not easy for the signed case, > but is do-able. It can be lowered to a division + a branch,
2009 Jun 01
3
[LLVMdev] [PATH] Fix support for .umul.with.overflow on x86 + fix c binding
Hi, The first patch fixes the implementation of umul.with.overflow on x86 which was throwing a 'Cannot yet select' error. The second patch fixes the definition of LLVMTypeKind in the C binding by syncing it with the c++ counterpart. Please review and commit if it looks ok. thanks Zoltan -------------- next part -------------- An HTML attachment was
2009 May 05
2
[LLVMdev] [PATH] Fixes for the amd64 JIT code
Hi Zoltan, The part that determines whether SIB byte is needed caused a lot of regressions last night (see Geryon-X86-64 etc.). I've reverted it for now. Please take a look. Thanks, Evan On May 4, 2009, at 3:49 PM, Evan Cheng wrote: > Committed as revision 70929. Thanks. > > Evan > > On May 3, 2009, at 8:29 PM, vargaz wrote: > >> >> Hi, >> >>
2009 May 05
1
[LLVMdev] [PATH] Fixes for the amd64 JIT code
Hi, It looks like the problem was with the RIP relative addressing. The original patch mistakenly removed the || DispForReloc part because I tough that the RIP relative addressing was done by the SIB encodings, but it is actually done by the shorter ones. The attached patch seems to work for me on linux and when simulating darwin by forcing some variables in X86TargetMachine.cpp to their darwin
2008 Dec 09
0
[LLVMdev] [PATH] Add sub.ovf/mul.ovf intrinsics
Applied. Thanks, Zoltan! -bw On Tue, Dec 9, 2008 at 1:12 PM, Zoltan Varga <vargaz at gmail.com> wrote: > Hi, > > Attached is the final version of the patch, adding the requested > FIXME. If this is ok, can > somebody check it in ? > > thanks > > Zoltan > > On Tue, Dec 9, 2008 at 9:58 PM,
2008 Dec 09
1
[LLVMdev] [PATH] Add sub.ovf/mul.ovf intrinsics
Hi, The add.with.overflow instrinsics don't seem to work with constant arguments, i.e. changing the call in add-with-overflow.ll to: %t = call {i32, i1} @llvm.sadd.with.overflow.i32(i32 0, i32 0) causes the following exception when running the codegen tests: llc: DAGCombiner.cpp:646: void<unnamed>::DAGCombiner::Run(llvm::CombineLevel): Assertion `N->getValueType(0) ==
2009 Dec 08
2
[LLVMdev] LLVM intrinsic for SSE ANDPS instruction
Hi, The arguments to the 'and' instruction must be integer types or vectors of integer types. If I have a compiler whose source language has support for andps by having its own intrinsics, then I would have to generate code to convert the float vector into an int vector before passing it to llvm's and instruction, then convert the result back.
2009 May 05
0
[LLVMdev] [PATH] Fixes for the amd64 JIT code
Hi, I can't reproduce these failures on my linux machine. The test machine seems to be running darwin. I suspect that the problem might be with RIP relative addressing, or with the encoding of R12/R13, but the code seems to handle the latter, since it checks for ESP/EBP which is the same as R12/R13. Zoltan On Tue, May 5, 2009 at 8:18 PM, Evan Cheng <evan.cheng at
2009 Dec 15
3
[LLVMdev] code generation for calls in JITted code after r88984
Hi, After this commit: http://llvm.org/viewvc/llvm-project?view=rev&revision=88984 the X86 JIT no longer emits calls using call <ADDR>, but always uses mov REG, <ADDR>, call *REG. This causes problems for the usage of LLVM in JITs since the JIT can no longer patch the callsite after the callee have been compiled. According to the comments for the commit, this was done to fix the
2009 Dec 08
0
[LLVMdev] LLVM intrinsic for SSE ANDPS instruction
Hi Zoltan, I think the bitcast operation is rather painless to use. And if you want to be able to execute it on a float vector you could try putting the and operation in a function with inline linkage and that would be all that's needed to convert over and back. BTW, bitcasting is a no-op conversion in actual code. --Sam Crow > >From: Zoltan Varga <vargaz at gmail.com>
2009 May 04
0
[LLVMdev] [PATH] Fixes for the amd64 JIT code
Committed as revision 70929. Thanks. Evan On May 3, 2009, at 8:29 PM, vargaz wrote: > > Hi, > > If this looks ok, could somebody check it in ? > > thanks > > Zoltan > > > Evan Cheng-2 wrote: >> >> Looks good. Thanks. >> >> Evan >> >> On May 1, 2009, at 8:40 AM, Zoltan Varga wrote: >>
2008 Dec 09
0
[LLVMdev] [PATH] Add sub.ovf/mul.ovf intrinsics
On Tue, Dec 9, 2008 at 6:11 AM, Zoltan Varga <vargaz at gmail.com> wrote: > Hi, > > Here is the next iteration of the patch. The only comment not > addressed is this one: > Thanks! It's looking good. >> It would be better to implement a target-independent check for >> overflow for the "Legal" case (like how SADDO does). Hacker's > Delight
2008 Dec 15
2
[LLVMdev] [PATH] Add missing functionality to the C binding
Hi, This is a resend of a previous patch which had no responses. The attached patch adds some missing functions to the C binding: - ability to insert previously created instructions using a builder - creation of aliases - creation of inline asm constants Please review and apply if it looks ok. thanks Zoltan -------------- next part -------------- A non-text attachment
2009 Jun 01
0
[LLVMdev] [PATH] Fix support for .umul.with.overflow on x86 + fix c binding
Hi, Forgot the patch... Zoltan On Mon, Jun 1, 2009 at 10:57 PM, Zoltan Varga <vargaz at gmail.com> wrote: > Hi, > > The first patch fixes the implementation of umul.with.overflow on x86 > which was throwing a 'Cannot yet select' error. > The second patch fixes the definition of LLVMTypeKind in the C binding by > syncing it with the c++
2009 Dec 15
0
[LLVMdev] code generation for calls in JITted code after r88984
On Tue, Dec 15, 2009 at 1:05 AM, Zoltan Varga <vargaz at gmail.com> wrote: > Hi, > > After this commit: > http://llvm.org/viewvc/llvm-project?view=rev&revision=88984 > > the X86 JIT no longer emits calls using call <ADDR>, but always uses mov > REG, <ADDR>, call *REG. That should only be the x86-64 JIT. If the x86-32 JIT does that, it's definitely a