search for: x86isellowering

Hi Evan, The commit http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060327/033389.html broke CVS. The attached obvious patch fixes it. I don't have write access . So can someone commit this in ? ramana at zirakzigil:~/fsf/llvm/llvm/lib/Target/X86$ cvs diff -au X86ISelLowering.cpp Index: X86ISelLowering.cpp =================================================================== RCS file: /var/cvs/llvm/llvm/lib/Target/X86/X86ISelLowering.cpp,v retrieving revision 1.139 diff -a -u -r1.139 X86ISelLowering.cpp --- X86ISelLowering.cpp 28 Mar 2006 08:27:15 -0000 1.139 +++ X86...

Ignore the suggested fix in my earlier post. How about this? diff --git a/lib/Target/X86/X86ISelLowering.cpp b/lib/Target/X86/X86ISelLowering.cpp index 20c81c3..b8ebf42 100644 --- a/lib/Target/X86/X86ISelLowering.cpp +++ b/lib/Target/X86/X86ISelLowering.cpp @@ -1632,10 +1632,11 @@ X86TargetLowering::X86TargetLowering(const X86TargetMachine &TM, if (!Subtarget.is64Bit()) { // These libcalls...

Hi Sanjay, Some time ago you implemented a sext(add_nsw(x, C)) --> add(sext(x), C_sext) transformation in X86ISelLowering https://reviews.llvm.org/D13757 Is there any reason why this transformation is limited to sexts and doesn’t support zexts? Thanks, Artur -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160719/cc3c8670/attach...

...t;craig.topper at gmail.com> wrote: > Here's a quick patch that fixes this. I don't know to avoid it in IR. I > haven't checked any other tests, but it does fix your case. I'll try to put > up a real phabricator tonight or tomorrow. > > diff --git a/lib/Target/X86/X86ISelLowering.cpp > b/lib/Target/X86/X86ISelLowering.cpp > index e31f2a6..d79c0be 100644 > --- a/lib/Target/X86/X86ISelLowering.cpp > +++ b/lib/Target/X86/X86ISelLowering.cpp > @@ -4837,6 +4837,11 @@ bool X86TargetLowering::isCheapToSpeculateCtlz() > const { > > bool X86TargetLowering::i...

...://llvm.org/bugs/show_bug.cgi?id=20134 , so I limited it to that pattern. It's probably worth noting that I'm currently fighting through casts of all kinds in IR (InstCombine) rather than the backend: What is the current status of this work? Does it make sense to patch the existing code in X86ISelLowering in order to support looking through zext or the generic solution will be available soon? Artur https://reviews.llvm.org/D22421 https://reviews.llvm.org/D22271 https://reviews.llvm.org/D22477 https://reviews.llvm.org/D20774 https://llvm.org/bugs/show_bug.cgi?id=27925 I'm very interested to see...

...4, at 1:16 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hello > > Chain operand is needed if the intrinsic is reading / writing memory. > > On Wed, Jul 23, 2014 at 8:02 PM, kewuzhang <kewu.zhang at amd.com> wrote: >> Hi guys, >> >> In X86ISelLowering.cpp >> >> I saw” >> ... >> case Intrinsic::x86_rdrand_16: >> case Intrinsic::x86_rdrand_32: >> …. >> case Intrinsic::x86_avx512_gather_qpd_512: >> case Intrinsic::x86_avx512_gather_qps_512: >> .. >> “ >> those intrinsics are handl...

Hi all, I've run into a case where the optimizer seems to be having trouble doing the "obvious" thing. Consider this code: ``` define i16 @foo(<8 x i16>* dereferenceable(16) %egress, <16 x i8> %a0) { %a1 = icmp slt <16 x i8> %a0, zeroinitializer %a2 = bitcast <16 x i1> %a1 to i16 %astore = getelementptr inbounds <8 x i16>, <8 x i16>*

...h. A repeat of the rc2 build repeated the mismatch. I diff'd the disassembly between phase 2 and phase 3 and the difference is the same on both builds. The difference follows: # diff x86isel_p{2,3}.s 2c2 < Phase2/Release/llvmCore-8.0.0-rc2.obj/lib/Target/X86/CMakeFiles/LLVMX86CodeGen.dir/X86ISelLowering.cpp.o: file format elf64-x86-64 --- > Phase3/Release/llvmCore-8.0.0-rc2.obj/lib/Target/X86/CMakeFiles/LLVMX86CodeGen.dir/X86ISelLowering.cpp.o: file format elf64-x86-64 121757c121757 < 863: 48 8b 84 24 e0 05 00 mov 0x5e0(%rsp),%rax --- > 863: 48 8b 84 24 b0 01...

...ty. But it will pretty much completely break the utility of looking at only a single layer of blame. Fortunately we have nice tools like 'git blame' that can step incrementally back through time. If anyone is radically opposed to me cleaning up TargetLowering.h, TargetLoweringBase.cpp, and X86ISelLowering.{h,cpp}, shout. Otherwise, I will clean this up with a vengence. I've CC'ed piles of folks who are actively contributing and might be seriously impacted to make sure I don't really make life horrible for folks. -Chandler -------------- next part -------------- An HTML attachment was sc...

Hi I want to replace all the return instructions in the program with pop <reg>; jmp <reg>. Should I use IRBuilder in LLVM IR level? I found that there is a IRBuilder::CreateIndirectBr Or Should I modify the code in lib/Target/X86/X86ISelLowering.cpp in backend ? I found that there is a X86TargetLowering::LowerCall Which is better? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180809/d4693cb8/attachment.html>

/Volumes/mrs5/net/llvm/llvm/llvm/lib/Target/X86/X86ISelLowering.cpp: In member function 'llvm::SDOperand llvm::X86TargetLowering::LowerTRAMPOLINE(llvm::SDOperand, llvm::SelectionDAG&)': /Volumes/mrs5/net/llvm/llvm/llvm/lib/Target/X86/X86ISelLowering.cpp: 5305: warning: dereferencing type-punned pointer will break strict- aliasing rules :-(

...449 Discussion on why Rust doesn't want to fix (a refused patch to libcore): https://github.com/rust-lang/rust/pull/26749 The error is coming from one of these files: lib/Target/X86/X86FastISel.cpp:3166: report_fatal_error("SSE register return with SSE disabled"); lib/Target/X86/X86ISelLowering.cpp:2107: report_fatal_error("SSE register return with SSE disabled"); lib/Target/X86/X86ISelLowering.cpp:2261: report_fatal_error("SSE register return with SSE disabled"); test/CodeGen/X86/nosse-error2.ll:4:; NOSSE: {{SSE register return with SSE disabled}} test/CodeG...

...nking about this, it strikes me that we could get rid of the target-specific operators and a lot of other manual checks if we just had another isel phase. Let's say we structured things this way: legalize | V manual lowering (X86ISelLowering) | V manual isel (X86ISelDAGToDAG) | V table-driven isel (.td files/X86GenDAGISel) | V manual isel (some to-be-design piece) The idea is that we keep the...

Hi guys, In X86ISelLowering.cpp I saw” ... case Intrinsic::x86_rdrand_16: case Intrinsic::x86_rdrand_32: …. case Intrinsic::x86_avx512_gather_qpd_512: case Intrinsic::x86_avx512_gather_qps_512: .. “ those intrinsics are handled by “LowerINTRINSIC_W_CHAIN”. How the “INTRINSIC_W_CHAIN” opCode is set instead of “INTRINSIC...

Just noticed that when we generate a custom lowering for some atomics that we forgot to transfer the MemOperand to the new instruction that touches memory. -- Mon Ping Index: lib/Target/X86/X86ISelLowering.cpp =================================================================== --- lib/Target/X86/X86ISelLowering.cpp (revision 53702) +++ lib/Target/X86/X86ISelLowering.cpp (working copy) @@ -6010,7 +6010,9 @@ for (int i=0; i <= lastAddrIndx; ++i) (*MIB).addOperand(*argOpers[i]); MIB.add...

Looks like I have run into the same issue reported in: https://bugs.llvm.org/show_bug.cgi?id=20871 Is there a fix or work-around for it? The bug report seems to be still open. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/46c1282d/attachment.html>

...s in function recurse through gdb(i.e gdb > p a.s) it gives me an uninitialized value. The problem occurs only when we have a function call within function to which we have passed a structure. Could someone guide me were can i look to fix this issue. I have started with LowerFormalArguments in X86ISelLowering.cpp file. Thanks Karthik

...add an intrinsics(named max_qb) in x86 backend. In include/llvm/IR/IntrinsicsX86.td, I add a intrinsics (GCCBuiltin). In clang( BuiltinsX86.def ), I add a BUILTIN. And in x86 backend , I change : the X86InstrInfo.td to add def X86max_qb_flag , X86InstrArithmetic.td to add define of instruction , X86ISelLowering.cpp to add SDnode. It's succeed when LLVM compilates.But there is an error “use of unknown builtin '__builtin_x86_max_qb' ”，when I test the intrinsics. I do not know what I should do.I have been stranded here for 2 days. Grate for any suggestions. Thanks a lot. -------------- next part...

...352 Next, let's look at the file view diffstat. This can be useful because it goes beyond simply identifying the files which grew the most. It actually describes which *functions* grew the most in those files, creating more opportunites to do something about the code growth. lib/Target/X86/X86ISelLowering.cpp [file];combineX86ShuffleChain([snip]) [function] 24864 lib/Target/X86/X86ISelLowering.cpp [file];combineMul([snip]) [function] 14907 lib/Target/X86/X86ISelLowering.cpp [file];combineStore([snip]) [function] 12220 ... tools/clang/lib/Sema/SemaExpr.cpp [file];clang::Sema::CheckCompareOper...

Hi all, The attachment supersedes the previous patch. It incorporates some feedback from Anton and takes the next step of merging the largely duplicated calling convention logic in X86ISelLowering. LowerCCCArguments, LowerX86_64CCCArguments and LowerFastCCArguments are merged and inlined directly into LowerFORMAL_ARGUMENTS. I moved LowerFORMAL_ARGUMENTS to the location where LowerCCCArguments was in order to facilitate review (otherwise the diff would contain no useful deltas), but it...