search for: vargaz

...atch, 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, >> >> 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 f...

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...

...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: > > >> Hi, >> >> Currently, llvm treats the loads from a null address as unreachable code, >> i.e.: >> load i32* null >> is transformed by some optimization pass into >> unreachable >> >> This...

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,

...r::run(llvm::Function&) + 128 15 llc 0x0000000000822a95 main + 2234 Zoltan On Tue, Dec 9, 2008 at 11:08 PM, Bill Wendling <isanbard at gmail.com> wrote: > 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 >> >>...

...IB 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 values. Zoltan On Tue, May 5, 2009 at 11:17 PM, Zoltan Varga <vargaz at gmail.com> wrote: > 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 th...

...her 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, >> >> If this looks ok, could somebody check it in ? >> >> thanks >> >> Zoltan >> >> >> Evan Cheng-2 wrote: >>> >>> Looks good. Thanks. >>> >>> E...

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

...ight (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, > >> > >> If this looks ok, could somebody check it in ? > >> > >> thanks > >> > >> Zoltan > >> > >> > >> Evan Cheng-2 wrote: > >>...

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 h...

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++ counterpart....

...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> >To: Evan Cheng <evan.cheng at apple.com> >Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >Sent: Tue, December 8, 2009 1:39:18 PM >Subject: Re: [LLVMdev] LLVM intrinsic for SSE ANDPS instruction > >Hi, > > The arguments to the 'an...

...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: > > Hi, > > Currently, llvm treats the loads from a null address as > unreachable code, i.e.: > load i32* null > is transformed by some optimization pass into > unreachable > > This presents problems in JIT compiler...

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

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 Varg...

On Tue, Dec 9, 2008 at 6:11 AM, Zoltan Varga <vargaz at gmail.com> wrote: >> 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...

...every remaining null check that your first pass inserted. It should first check whether the condition is in fact a constant true (since that reduction might not have been run after ptr became a constant null) and turn it into an unconditional trap. On Sat, Sep 5, 2009 at 4:59 PM, Zoltan Varga<vargaz at gmail.com> wrote: > 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, B...

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

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.

Hi, Currently, llvm treats the loads from a null address as unreachable code, i.e.: load i32* null is transformed by some optimization pass into unreachable This presents problems in JIT compilers like mono which implement null pointer checks by trapping SIGSEGV signals. It also looks incorrect since it changes program behavior, which might be undefined in general, but it is quite