search for: x86targetlowering

In file lib/Target/X86/X86ISelLowering.cpp Function X86TargetLowering::getRegClassForInlineAsmConstraint I think the second register must be X86::BL. else if (VT == MVT::i8) return make_vector<unsigned>(X86::AL, X86::DL, X86::CL, X86::DL, 0); Lauro -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm...

I'm tracking down an X86 code generation malfeasance regarding BT (bit test) and I have some questions. This IR *matches* and then *X86TargetLowering::LowerToBT **is called:* %and = and i64 %shl, %val * ; (val & (1 << index)) != 0 ; *bit test with a *register* index This IR *does not match* and so *X86TargetLowering::LowerToBT **is not called:* %and = lshr i64 %val, 25 * ; (val & (1 **<< 25)) != 0...

This is a patch to X86TargetLowering::LowerToBT() which was hashed over on the Developers list with Intel concurring. It checks whether the -Oz (optimize for size) flag is set or whether the containing function's PGO cold attribute is set. If either are true it emits BT for tests of bits 8-31 instead of TEST. Previously, TEST was...

...urrent clang. > > Thanks, > > Mehdi > > On Jan 18, 2015, at 5:13 PM, Chris Sears <chris.sears at gmail.com> wrote: > > I'm tracking down an X86 code generation malfeasance regarding BT (bit > test) and I have some questions. > > This IR *matches* and then *X86TargetLowering::LowerToBT **is called:* > > %and = and i64 %shl, %val * ; (val & (1 << index)) != 0 ; *bit > test with a *register* index > > > This IR *does not match* and so *X86TargetLowering::LowerToBT **is not > called:* > > %and = lshr i64 %val, 25 * ; (v...

...t apple.com> wrote: > Can you transform you C file into a LLVM IR lit test? > > See example in test/CodeGen/X86/*.ll > > Thanks, > > Mehdi > > > On Jan 24, 2015, at 11:47 AM, Chris Sears <chris.sears at gmail.com> wrote: > > > > This is a patch to X86TargetLowering::LowerToBT() which was hashed over > on the Developers list with Intel concurring. > > > > It checks whether the -Oz (optimize for size) flag is set or whether the > containing function's PGO cold attribute is set. If either are true it > emits BT for tests of bits 8-31 ins...

...;> On Jan 22, 2015, at 1:17 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: >> >> >> >>> Begin forwarded message: >>> >>> Date: January 18, 2015 at 10:57:33 PM PST >>> Subject: Re: [LLVMdev] X86TargetLowering::LowerToBT >>> From: Chris Sears <chris.sears at gmail.com <mailto:chris.sears at gmail.com>> >>> To: Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> >>> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu <mailt...

Is that even a valid instruction? I thought TEST only took 32-bit immediates. Fiona > On Jan 22, 2015, at 2:48 PM, Chris Sears <chris.sears at gmail.com> wrote: > > The problem is that REX TEST reg,#(1<<37) is 10 bytes vs 5 bytes for REX BT reg,37. > That's a large space penalty to pay for a possible partial update stall. > > So the idea of generating BT for

Yeah, the alternative is to do movabs and then test, which is doable but I’m not sure if it’s worth it (surely BT + risk of flags merging penalty has to be better than two ops, one of which is ~9-10 bytes). Fiona > On Jan 22, 2015, at 2:59 PM, Chris Sears <chris.sears at gmail.com> wrote: > > My bad on that. So that's what the comment meant. > That means BT is pretty much

That’s not how partial-flags update stalls work. There is no independent tracking of individual bits in EFLAGS. This means that BT + CMOVNZ has a false dependency on whatever instruction wrote to EFLAGS before BT and requires an extra µop vis-a-vis TEST + CMOVNZ or SHR + AND. Please do not use BT. It is a performance hazard. If you don’t believe me for some reason, here’s the relevant quote

Which BTQ? There are three flavors. BTQ reg/reg BTQ reg/mem BTQ reg/imm I can imagine that the reg/reg and especially the reg/mem versions would be slow. However the shrq/and versions *with the same operands* would be slow as well. There's even a compiler comment about the reg/mem version saying "this is for disassembly only". But I doubt BTQ reg/imm would be microcoded. -- Ite

...JCALLSTACKDOWN and ADJCALLSTACKUP? 6. + } else if (RetOpcode == X86::TCRETURNdi) { + // a tailcall adjust the stack ... + } else if (RetOpcode == X86::TCRETURNri) { + MBBI = prior(MBB.end()); Seems like there are quite a bit of duplicate code between the 2 cases. Please refactor. 7. X86TargetLowering::X86TargetLowering(TargetMachine &TM) : TargetLowering(TM) { + IsLastCallTailCall = false; This is probably not a good idea. You are assuming nodes are lowered in certain order, that is dangerous. It's probably better to check whether the last call is a tail call on the fly as you...

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 are not available in 32-bit. setLibcallName(RTLIB::SHL_I128, nullptr); setLibcallName(RTLIB::SRL_I128, nullptr); setLibcallName(RTLIB::SRA_I128, nullptr); + setLibcallName(RTLI...

On Thu Jan 22 2015 at 3:32:53 PM Chris Sears <chris.sears at gmail.com> wrote: > The status quo is: > > a) 40b REX+BT instruction for the 64b case > b) 48b TEST for the 32b case > c) unless it's small TEST > > > You are currently paying a 16b penalty for TEST vs BT in the 32b case. > That may be worth testing the -Os flag. > You'll want -Oz here, Os

Hi Evan, first off thanks to you and Chris for taking time. On 6 Sep 2007, at 00:57, Evan Cheng wrote: > We'd like to see tail call optimization to be similar to the target > independent lowering of ISD::CALL nodes. These are auto-generated > from ???CallingConv.td files. Some target specific details such as > function address register (ECX in your example) should be coded in

...g as per the > ABI (the GCC ABI, I'll add). > >  1. Is there a LLVM way of dealing with this without using separate code >  for VC++ and GCC? I'm not sure what you mean... LLVM can distinguish between MinGW and MSVC targets. If we want to, it shouldn't be too hard to make X86TargetLowering::LowerFormalArguments and X86TargetLowering::LowerCall account for the difference. >  3. Is a bug that LLVM does not distinguish among GCC and VC++ sret >  handling? Probably... see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834 . -Eli

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

...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::isLoadBitCastBeneficial(EVT LoadVT, > EVT BitcastVT) const { > + if (!LoadVT.isVector() && BitcastVT.isVector() && > + BitcastVT.getVectorElement...

...e, CallingConv)) Note that I interpreted the following paragraph of you: > IsEligibleForTailCallElimination() should be a target hook. This way > TargetLowering::LowerCallTo() can determine whether a call is > eligible for tail call elimination and insert the current ISD::CALL > node. X86TargetLowering::LowerX86_32FastCCCallTo() will not have to > handle non-tail calls. in the following way: I check in TargetLowering:LowerCallTo whether the call IsEligibleForTailCallElimination and insert a ISD:CALL node with the tailcall attribute set or not. Then in X86TargetLowering::LowerCALL i can dis...

Let's go directly to the example struct S { double dummy1; double dummy2; }; S bar(); S foo() { return bar(); } This is the result of g++ -c -S -O2 (focus on the final `ret'): __Z3foov: LFB0: pushl %ebp LCFI0: movl %esp, %ebp LCFI1: pushl %ebx LCFI2: subl $20, %esp LCFI3: movl 8(%ebp), %ebx movl %ebx, (%esp) call __Z3barv pushl %eax movl %ebx, %eax movl -4(%ebp), %ebx

...(RetOpcode == X86::TCRETURNdi) { > + // a tailcall adjust the stack > ... > + } else if (RetOpcode == X86::TCRETURNri) { > + MBBI = prior(MBB.end()); > > Seems like there are quite a bit of duplicate code between the 2 > cases. Please refactor. Okay dokey > 7. > X86TargetLowering::X86TargetLowering(TargetMachine &TM) > : TargetLowering(TM) { > + IsLastCallTailCall = false; > > This is probably not a good idea. You are assuming nodes are lowered > in certain order, that is dangerous. It's probably better to check > whether the last call is a ta...