similar to: Replace "ret" with "pop+jump"

Sent from my iPhone > On Jun 28, 2016, at 2:27 PM, Matthias Braun <matze at braunis.de> wrote: > > >> On Jun 28, 2016, at 10:09 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >> >> Sent from my iPhone >> >>> On Jun 28, 2016, at 12:53 PM, vivek pandya <vivekvpandya at gmail.com> wrote:

> On Jun 28, 2016, at 10:09 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > Sent from my iPhone > > On Jun 28, 2016, at 12:53 PM, vivek pandya <vivekvpandya at gmail.com <mailto:vivekvpandya at gmail.com>> wrote: > >> >> >> On Tue, Jun 28, 2016 at 8:11 PM, Mehdi Amini <mehdi.amini at apple.com

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

> On Jun 28, 2016, at 3:01 PM, Matthias Braun <matze at braunis.de> wrote: > >> >> On Jun 28, 2016, at 11:34 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> >> Sent from my iPhone >> >> On Jun 28, 2016, at 2:27 PM, Matthias Braun <matze at braunis.de

We should handle this a lot better after r34763 ~Craig On Mon, Nov 26, 2018 at 3:13 PM Craig Topper <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

Sent from my iPhone > On Jun 28, 2016, at 12:53 PM, vivek pandya <vivekvpandya at gmail.com> wrote: > > > >> On Tue, Jun 28, 2016 at 8:11 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >>> On Jun 27, 2016, at 12:25 PM, vivek pandya <vivekvpandya at gmail.com> wrote: >>> >>> Hello , >>> >>> To solve

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

> On Jun 28, 2016, at 11:34 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > Sent from my iPhone > > On Jun 28, 2016, at 2:27 PM, Matthias Braun <matze at braunis.de <mailto:matze at braunis.de>> wrote: > >> >>> On Jun 28, 2016, at 10:09 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org

I have tried out the following code which examines each call site in a module for tail call and do not perform optimization in such case: On Wed, Jun 29, 2016 at 12:34 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Jun 28, 2016, at 3:01 PM, Matthias Braun <matze at braunis.de> wrote: > > > On Jun 28, 2016, at 11:34 AM, Mehdi Amini via llvm-dev < >

for example I want to insert a new machine bb “before” a specific machine bb. or split a mbb and keep the later one as the original one. (to keep the label/Blackadder's correct t) (or keep other property of mbb) so I need to transfer the original mbb's predecessor to the new mbb. Nicolai Hähnle <nhaehnle at gmail.com> 於 2020年3月13日 週五 23:57 寫道： > On Fri, Mar 13, 2020 at

/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 :-(

Hey Evan, At the point of the instructions you suggested I step through, X86ISelLowering has this state: - this 0x00000000005fe728 {VarArgsFrameIndex=-842150451 RegSaveFrameIndex=-842150451 VarArgsGPOffset=3452816845 ...} llvm::X86TargetLowering * const + llvm::TargetLowering {TM={...} TD=0x00000000008edac0

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>

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:

On Feb 12, 2008, at 5:26 PM, Chuck Rose III wrote: > Hola LLVMers, > > I’m debugging through some strangeness that I’m seeing on X64 on > windows with LLVM2.2. I had to change the code so that it would > engage the x64 target machine on windows builds, but I’ve otherwise > left LLVM 2.2 alone. The basic idea is that I’ve got a function bar > which is compiled by

So if I want to know whether a CallInst is a C++ virtual call or not. I have to get the information at frontend/Clang. and then pass the information to middle-end/LLVM IR by myself. Is it right? Thank you David Blaikie <dblaikie at gmail.com> 於 2020年6月19日 週五 上午1:26寫道： > On Thu, Jun 18, 2020 at 9:53 AM PenYiWang via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > >

I tried to compile on Windows ( using the win32/llvm.sln in MSVC Express 2008 ) the new 2.3 branch and here are the results: 1. I needed to copy the file Configure.exe.embed.manifest to Configure.exe.intermediate.manifest . This is a bug from the previous llvm release (2.2) 2. I copied the file SimplifyLibCalls.cpp from lib/Transforms/Scalar to lib/Transforms/IPO. I think the position of

On Jul 1, 2009, at 2:22 PMPDT, Dan Gohman wrote: >> Ops.push_back(DAG.getConstant(1, MVT::i32)); >> Chain = DAG.getNode(ISD::ADD, DAG.getVTList(MVT::Other, MVT::i32), >> &Ops[0], Ops.size()); >> >> Isn't that the way how it is supposed to work? > > ADD does not use a chain, so there's no chain operand, or > MVT::Other result for it in an ADD

On Mar 17, 2011, at 9:32 AM, David A. Greene wrote: > Chris Lattner <clattner at apple.com> writes: >>> 1. We have special target-specific operators for certain shuffles in X86, >>> such as X86unpckl. > >> It also eliminates a lot of fragility. Before doing this, X86 >> legalize would have to be very careful to specifically form shuffles >> that

Hi, I found some suspicious code in X86TargetLowering::getRegClassForInlineAsmConstraint, but I don't know if it's a bug or my poor understanding of what the code does. This is the code in question: (lib/Target/X86/X86ISelLowering.cpp:5064) if (VT == MVT::i32) return make_vector<unsigned>(X86::EAX, X86::EDX, X86::ECX, X86::EBX, 0); else if (VT == MVT::i16) return