similar to: [LLVMdev] disabling fastcc

If you can't make an executable test from C or C++ code then how do you know something works. Just by examination of the .s? On 09/30/2014 03:18 PM, Reed Kotler wrote: > If I wanted to call this function that they generated by hand, from C or > C+ code, how would that be done? > > if have seen cases where a real boolean gets generated but it was > something fairly involved.

Yes, you could have mips16 and fastcc. Mips16 just means that processor mode to execute that function is "mips16". So in a mips16 designated function, I will just emit mips16 instructions and in a "nomips16" function, just emit normal mips32 instructions. I tend to call this "mips32" normal mode, "standard encoding" because in reality the processor is

I understand that but falling back makes the compilation slower. I'm wondering what could be done to remove this restriction about fast-isel not being able to handle non legal types. ________________________________________ From: Anton Korobeynikov [anton at korobeynikov.info] Sent: Sunday, August 31, 2014 12:55 AM To: Reed Kotler Cc: LLVMdev at cs.uiuc.edu Subject: Re: [LLVMdev] lowering

I think that Bill Wendlings new attribute implementation would allow me to do this but it is not ready yet. Maybe it's okay to just add them to the list of function attributes as I suggested. But in the end, someone has to approve the checkin. On 01/11/2013 07:35 AM, Reed Kotler wrote: > Yes, you could have mips16 and fastcc. > > Mips16 just means that processor mode to execute

Technically I don't need C/C++ code for it. I'm not really very good at writing LLVM assembly code by hand (but I should be - lol ). I'm working on fast-isel and I want to have executable tests for all of this and not just make check tests. It's easier for me to do that in C/C++ and then save the .ll and morph it into a make check test. I'm going through the fast-isel

Thanks. So what about a fragment like this: (taken from fast-isel.ll in X86 ) define void @ptrtoint_i1(i8* %p, i1* %q) nounwind { %t = ptrtoint i8* %p to i1 store i1 %t, i1* %q ret void } TIA. On 09/29/2014 02:16 PM, Duncan P. N. Exon Smith wrote: >> On Sep 29, 2014, at 1:51 PM, reed kotler <rkotler at mips.com> wrote: >> >> What kind of C or C++ code will emit

What is the purpose of tablegen created files for fast-isel? If I make the following change to Makefile in lib/Target/Mips BUILT_SOURCES = MipsGenRegisterInfo.inc MipsGenInstrInfo.inc \ MipsGenAsmWriter.inc MipsGenCodeEmitter.inc \ MipsGenDAGISel.inc MipsGenCallingConv.inc \ - MipsGenSubtargetInfo.inc MipsGenMCCodeEmitter.inc \ +

On Feb 17, 2013, at 1:01 PM, Reed Kotler <rkotler at mips.com> wrote: > On 02/17/2013 12:48 PM, Andrew Trick wrote: >> On Feb 16, 2013, at 1:31 PM, Cameron Zwarich <zwarich at apple.com> wrote: >> >>> That's exactly the right place. >> Really? You don't want the expansion to be optimized? You want to specify a machine model for the pseudo's

Fast-isel is not equipped in general to deal with non legal types. It would seem that an llvm assembler pass run after clang but before llvm could do the lowering though. Any thoughts? Reed

Depends on whether its actually the calling convention, or just an annotation (I don't know MIPS that well). Could you ever have a case where you want to declare a function as both mips16 and fastcc, or some other explicit calling convention? For PTX, we added two calling conventions to mark kernel functions (callable by host) from device functions (not callable by host). But this

On Feb 16, 2013, at 1:31 PM, Cameron Zwarich <zwarich at apple.com> wrote: > That's exactly the right place. Really? You don't want the expansion to be optimized? You want to specify a machine model for the pseudo's as if they're real instructions? You don't want to schedule or register allocate the real instructions? -Andy > On Feb 16, 2013, at 1:08 PM, Reed

On 02/17/2013 01:08 PM, Andrew Trick wrote: > > On Feb 17, 2013, at 1:01 PM, Reed Kotler <rkotler at mips.com > <mailto:rkotler at mips.com>> wrote: > >> On 02/17/2013 12:48 PM, Andrew Trick wrote: >>> On Feb 16, 2013, at 1:31 PM, Cameron Zwarich<zwarich at apple.com> wrote: >>> >>>> That's exactly the right place.

In the following example with gcc style builtins, in once case llvm.powi.f64 is emitted and in the other just a call to library function powf. ~/llvm/build/Debug+Asserts/bin/clang -S -emit-llvm pow1.c Why is that? Is there a way to force the call to an llvm style builtin? Tia. Reed -------------- next part -------------- A non-text attachment was scrubbed... Name: pow1.c Type: text/x-csrc

Is there a simple way to add a comment in the machine instructions of a basic block? Ideally something that can be used with machine instruction builder. Tia. Reed

On 01/29/2014 04:25 PM, Rafael Espíndola wrote: >> How would this pass get added to the chain? >> >> It has to create more functions and then those in turn need to be compiled. > I am sure it can be done. MergeFunctions for example creates new functions. > > Now, it does seem this request/code review is a bit upside down. You > have been told that your original

Ok. I'm basically just following the model of the other fast-isel ports. On 01/30/2015 09:12 PM, David Blaikie wrote: > (I'm assuming you're building LLVM with clang, in this case?) > > Looks like IntrinsicInst is one of those "lies" in LLVM that works via > type punning that's undefined behavior in C++, so it's code that > should be fixed anyway.

During ISel lowering, there are some stubs I realize that I need to emit during AsmPrinter. The question is: where to store that information? As a hack it could be stored in Subtarget. If there is a reasonable place to put it, it could be store in Module. Any ideas? It's just a list of functions that I need to generate stubs for. I know the possible elements of the list. It's a

On Fri, Jan 30, 2015 at 10:37 PM, reed kotler <rkotler at mips.com> wrote: > Ok. > > I'm basically just following the model of the other fast-isel ports. > Yeah, not your fault - just an architectural quirk. It's possible we could workaround the debug info side of this by declaring the virtual dtor (or some other virtual function - even an explicit anchor as we have

I see what my problem is here.... I'll continue to move further. Seems like Richards fix is still okay. On 02/25/2014 02:42 PM, Eric Christopher wrote: > On Tue, Feb 25, 2014 at 2:41 PM, reed kotler <rkotler at mips.com> wrote: >> On 02/25/2014 02:38 PM, Eric Christopher wrote: >>> On Tue, Feb 25, 2014 at 2:32 PM, reed kotler <rkotler at mips.com> wrote:

On 01/29/2014 02:18 PM, Rafael Espíndola wrote: >> I'd like to just check my code in and then you can look at it in it's >> totality and see if you have >> a better solution . > No! > > If it is the compiler creating instructions, it is not inline > assembly. If you need to print mips16 and mips32 and they are two > independent instruction sets, my guess is