similar to: Fusing contract fadd/fsub with normal fmul

On Jun 16, 2009, at 7:34 AM, Aaron Gray wrote: >> The LLVM IR opcodes Add, Sub, and Mul have been each split into >> two. Add, Sub, and Mul now only handle integer types, and three >> new opcodes, FAdd, FSub, and FMul now handle floating-point types. > > Dan, > > Wondering the reason why there is no FDiv ? FDiv already exists; div was split quite a while ago. Dan

> The LLVM IR opcodes Add, Sub, and Mul have been each split into > two. Add, Sub, and Mul now only handle integer types, and three > new opcodes, FAdd, FSub, and FMul now handle floating-point types. Dan, Wondering the reason why there is no FDiv ? Thanks, Aaron

----- Original Message ----- From: "Dan Gohman" <gohman at apple.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Tuesday, June 16, 2009 7:49 AM Subject: Re: [LLVMdev] Upcoming API change: FAdd, FSub, FMul > > On Jun 16, 2009, at 7:34 AM, Aaron Gray wrote: > >>> The LLVM IR opcodes Add, Sub, and Mul have been each split

Hello, The LLVM IR opcodes Add, Sub, and Mul have been each split into two. Add, Sub, and Mul now only handle integer types, and three new opcodes, FAdd, FSub, and FMul now handle floating-point types. The main LLVM APIs are currently preserving backwards compatibility, transparently mapping integer opcodes to corresponding floating-point opcodes when the operands have floating-point types.

It's out of date. We're using MCJIT on ARM to implement an OpenCL on CPU implementation. It works! On Tue, Nov 25, 2014 at 3:46 PM, Yichao Yu <yyc1992 at gmail.com> wrote: > On Tue, Nov 25, 2014 at 4:22 PM, Yichao Yu <yyc1992 at gmail.com> wrote: >> Hi, >> >> I am sorry if this question have been brought up too many times but >> the document does

On 26 November 2014 at 00:14, Yichao Yu <yyc1992 at gmail.com> wrote: >> We're using MCJIT on ARM to implement an OpenCL on CPU implementation. It works! > > Thanks. Great to hear that!!! > > Maybe could someone please update that page.... It's really confusing. Hi Yichao, So, MCJIT works well for x86 and PPC, and it works to a degree on ARM. Tom's team has

Hi All, Recently I was doing some AArch64 work and noticed some cases where fmuls were not getting fused with fadds. Is there any particular reason that the AArch64 machine combiner doesn't do this like it does for add/mul? I am happy to work up a patch for this, but I wanted to make sure that there wasn't a good reason for it not already being there. FWIW, I see where GCC is doing

Hi, I am sorry if this question have been brought up too many times but the document does seems a little bit confusing on this. According to the official feature page[1] ARM is not a supported target (for JIT at least...). However, according to this email[2] on the list and this related bug report[3] from earlier this year, it seems that the JIT engine is working well on ARM. Is the feature

On Fri, Sep 18, 2015 at 10:34 PM, Tim Northover <t.p.northover at gmail.com> wrote: > AArch64's fmadd instruction is fused, which means it can produce a > different result to the two operations executed separately. The C and > C++ standards do not allow such changes. Sorry, sloppy language on my part. I was aware of fmadd, but I was really asking about turning sequences like:

Hi, >From LangRef, these intrinsics seems really useful for letting LLVM know about certain higher level immutability guarantee, e.g. for objects that are not allowed to be mutated after construction. However, it doesn't seem to work[1] and a quick code search suggests that there's not a single optimization pass that's currently using it for store to load forwarding, only very few

Hi, I just got my git account joining into LLVM. When I tried a test push, I got git push origin HEAD:master --dry-run Username for 'https://github.com': stephan-yichao-zhao Password for 'https://stephan-yichao-zhao at github.com': remote: Invalid username or password. fatal: Authentication failed for 'https://github.com/llvm/llvm-project.git/' The page says "Your

> We at Azul have been using invariant.start for marking objects as immutable after a certain point. > Also, upstream changes to teach relevant optimizations about invariant.start and end were added > last year. > > With respect to store to load forwarding, this is handled in GVN. I think the test cases in test/Transforms/GVN/invariant.start.ll > handle what you’re looking for.

In my target, I have setOperationAction(ISD::FSUB, MVT::v4f32, Expand); This produces the desired effect in LegalizeDAG, replacing the FSUB with FADD + FNEG. However, when the vector legalizer runs, it thinks the Expand legalize action means to unroll the vector. This isn't necessary and not what I wanted. Is there a way to get one and not the other? I don't want the unroll aspect of

> We do not implement that restricted semantics correctly either -- see > https://bugs.llvm.org/show_bug.cgi?id=27190 Haha, I wondered for a minute whether I should bring up that bug... We've seen pretty nasty crashes due to it and had to work around it..... One of my recent work has also uncovered another (I believe) invalid handling of returns_twice functions....

HI Yichao, RTDyldObjectLinkingLayer has a NotifyObjectLoaded hook that you can use to call NotifyObjectEmitted on your GDBRegistrationListener. If code is going to be unloaded we would have to add an extra hook to call NotifyFreeingObject -- that seems totally reasonable to add. -- Lang. On Wed, Oct 11, 2017 at 10:44 AM, Yichao Yu <yyc1992 at gmail.com> wrote: > > What debugging

Hi, Thank you for all your helpful comments. To sum up, below is the list of correct folding examples for fadd: (1) fadd %x, -0.0 -> %x (2) fadd undef, undef -> undef (3) fadd %x, undef -> NaN (undef is a NaN which is propagated) Looking through the code I found the "NoNaNs" flag accessed through an instance of

Hi Duncan, On 17.09.2014 21:10, Duncan Sands wrote: > Hi Oleg, > > On 17/09/14 18:45, Oleg Ranevskyy wrote: >> Hi, >> >> Thank you for all your helpful comments. >> >> To sum up, below is the list of correct folding examples for fadd: >> (1) fadd %x, -0.0 -> %x >> (2) fadd undef, undef -> undef

On Oct 31, 2017, at 3:50 PM, Anna Thomas via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On Oct 31, 2017, at 12:17 PM, Yichao Yu <yyc1992 at gmail.com<mailto:yyc1992 at gmail.com>> wrote: We at Azul have been using invariant.start for marking objects as immutable after a certain point. Also, upstream changes to teach relevant

As far as I know, LLVM does not try very hard to guarantee constant folded NaN payloads that match exactly what the target would generate. —Owen > On Sep 16, 2014, at 10:30 AM, Oleg Ranevskyy <llvm.mail.list at gmail.com> wrote: > > Hi Duncan, > > I reread everything we've discussed so far and would like to pay closer attention to the the ARM's FPSCR register

Hi Connor, ...The LLVM documentation has a page at > llvm.org/docs/DebuggingJITedCode.html > showing an example of using gdb to debug MCJIT’ed code, but has no mention > of ORC JIT. What debugging support MCJIT has is provided by the RuntimeDyld utility, which ORC shares. I would expect anything in that document to apply to ORC as well, though I haven't tested it personally.