search for: midlevel

Hi Craig, thanks for digging into this. So InstCombine is the wrong place for fixing PR34474. Can you give me a hint where such an optimization should go into CodeGen? I am not really familiar with stuff that happens after the MidLevel. Cheers, Michael Am 13.09.2017 um 19:21 schrieb Craig Topper: > And that is less instructions. So from InstCombine's perspective the > multiply is the correct answer. I think this transformation is better > left to codegen where we know whether multiply or shift is truly better. &g...

...vpsrld $16, %xmm0, %xmm1 > vpor %xmm1, %xmm0, %xmm0 > vpextrb $0, %xmm0, %eax > > > However, on AArche64 I encountered an unreachable where codegen does not > know how to promote the i1 type. Since I am more familiar with the > midlevel I have to start digging into codegen. Any hints where to start > would be awesome. > > Cheers, > Michael > > Am 04.08.2017 um 08:18 schrieb Renato Golin: > > On 3 August 2017 at 19:48, Haidl, Michael via llvm-dev > > <llvm-dev at lists.ll...

...l.haidl at uni-muenster.de>> wrote: > Hi Craig, > > thanks for digging into this. So InstCombine is the wrong place for > fixing PR34474. Can you give me a hint where such an optimization should > go into CodeGen? I am not really familiar with stuff that happens after > the MidLevel. > > Cheers, > Michael > > Am 13.09.2017 um 19:21 schrieb Craig Topper: > > And that is less instructions. So from InstCombine's perspective the > > multiply is the correct answer. I think this transformation is better > > left to codegen where we know whether...

...m0 > > vpextrb $0, %xmm0, %eax > > > > > > However, on AArche64 I encountered an unreachable where > codegen does not > > know how to promote the i1 type. Since I am more familiar > with the > > midlevel I have to start digging into codegen. Any hints > where to start > > would be awesome. > > > > Cheers, > > Michael > > > > Am 04.08.2017 um 08:18 schrieb Renato Golin: > > > On 3 August 2017...

...> >> thanks for digging into this. So InstCombine is the wrong place for >> fixing PR34474. Can you give me a hint where such an optimization >> should >> go into CodeGen? I am not really familiar with stuff that happens >> after >> the MidLevel. >> >> Cheers, >> Michael >> >> Am 13.09.2017 um 19:21 schrieb Craig Topper: >> > And that is less instructions. So from InstCombine's perspective the >> > multiply is the correct answer. I think this transformation is better &...

Hi, My organization is doing a technology comparison between GCC optimization/backend and LLVM infrastructures to select the best environment for our next product. Would you please help me to find answers on the following features’ list support availability inside current (or near future) LLVM implementation: 1. Intrinsic function support 2. Semi-standard embedded C types (complex, fractional)

...> >> thanks for digging into this. So InstCombine is the wrong place for >> fixing PR34474. Can you give me a hint where such an optimization >> should >> go into CodeGen? I am not really familiar with stuff that happens >> after >> the MidLevel. >> >> Cheers, >> Michael >> >> Am 13.09.2017 um 19:21 schrieb Craig Topper: >> > And that is less instructions. So from InstCombine's perspective the >> > multiply is the correct answer. I think this transformation is better &...

Hi Amara, thank you for the clarification. I tested the intrinsics x86_64 and it seemed to work pretty well. Looking forward to try this intrinsics with the AArch64 backend. Maybe I find the time to look into codegen to get this intrinsics out of experimental stage. They seem pretty useful. Cheers, Michael -----Original Message----- From: Amara Emerson [amara.emerson at gmail.com] Received:

Hi, I'm working on a tool (KLEE) that interprets LLVM bitcode. One of the things it does is it instruments the LLVM bitcode with checks for division by zero. It does this by injecting calls to a function "klee_div_zero_check(long long divisor)" just before every division instruction (e.g. SDiv). These checks are injected by a pass that has been implemented in KLEE. This

...sure in some cases). And some of our cost modeling on IR sort of depends on the fact that constants are not instructions. I mean, we don't need constants; at an extreme we could have a constantint instruction, like GlobalISel's G_CONSTANT. But it's not clear that would be helpful for midlevel optimizations. For scalable vectors in particular, currently, the only way to express a vector with where every element is a simple integer is using a splat shuffle expression, and those often fold into some instruction. Continuing to use constant expressions for that will make that work more smo...

...for digging into this. So InstCombine is the wrong place for > >> fixing PR34474. Can you give me a hint where such an optimization > >> should > >> go into CodeGen? I am not really familiar with stuff that happens > >> after > >> the MidLevel. > >> > >> Cheers, > >> Michael > >> > >> Am 13.09.2017 um 19:21 schrieb Craig Topper: > >> > And that is less instructions. So from InstCombine's perspective > the > >> > multiply is the correct answer....

There is in fact a transform out there somewhere that reverses yours. define i64 @foo(i64 %a) { %b = shl i64 %a, 5 %c = add i64 %b, %a ret i64 %c } becomes define i64 @foo(i64 %a) { %c = mul i64 %a, 33 ret i64 %c } ~Craig On Wed, Sep 13, 2017 at 10:11 AM, Craig Topper <craig.topper at gmail.com> wrote: > Your code seems fine. InstCombine can infinite loop if some other

> -----Original Message----- > From: Chris Lattner <clattner at nondot.org> > Sent: Wednesday, February 5, 2020 4:02 PM > To: Eli Friedman <efriedma at quicinc.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: [EXT] Re: [llvm-dev] [RFC] Extending shufflevector for vscale vectors > (SVE etc.) > > On Jan 29, 2020, at 4:48 PM, Eli Friedman via

...tream, kexec-tools and other external packages being a priority in the short term. After this we plan to reexamine what is left and consider next steps. In the meantime it should be much easier these days to provide upstream configure options to provide the changes currently patched in by Debian. Midlevel library stability ========================== libxenlight is only API not ABI stable. This is a pain in particular for libvirt which needs binNMU for new Xen package. We would like to eventually offer ABI stability or this library, but we are not there yet. Stubdomains =========== Hard to do in...