search for: rlsosborn

...In regards to naming fastcc is easy to confuse with X86 fastcall calling convention. I think it would be sensible to add LLVM to the name when exposing it to users as this clearly implies that the calling convention is a non-portable, LLVM specific thing (e.g. llvm_fastcc). [1] https://github.com/rlsosborne/tool_axe

On Feb 20, 2013, at 7:52 PM, John McCall <rjmccall at apple.com> wrote: > On Feb 20, 2013, at 7:49 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >> On Wed, Feb 20, 2013 at 06:30:53PM -0800, John McCall wrote: >>> On Feb 20, 2013, at 6:24 PM, Richard Smith <richard at metafoo.co.uk> wrote: >>>> On Wed, Feb 20, 2013 at 6:18 PM, John McCall

Richard Pennington wrote: > Eli Friedman wrote: > >> I haven't looked at the rest of the email carefully, but why aren't >> you just implementing MULHU and MULHS? There's no point to >> implementing the *MUL_LOHI variants if the processor doesn't have >> them. >> > > I have implemented MULHU and MULHS. But if I take out my

sanjiv gupta wrote: > I have a question: > In the pattern below from X86 > > def INC8r : I<0xFE, MRM0r, (outs GR8 :$dst), (ins GR8 :$src), > "inc{b}\tdst", > [(set GR8:$dst, (add GR8:$src, 1))]>; > > Since we are emitting only "inc $dst", > What makes sure that the $src and $dst are same register? > > - Sanjiv It's enclosed

sanjiv gupta wrote: > On Tue, 2008-09-23 at 13:33 +0100, Richard Osborne wrote: > >> sanjiv gupta wrote: >> >>> I have a question: >>> In the pattern below from X86 >>> >>> def INC8r : I<0xFE, MRM0r, (outs GR8 :$dst), (ins GR8 :$src), >>> "inc{b}\tdst", >>> [(set GR8:$dst, (add GR8:$src, 1))]>;

Evan Cheng wrote: > On Jul 3, 2008, at 3:07 PM, Richard Osborne wrote: > >>> This seems to break the convention. It should be the responsibility >>> of the caller to further legalize the results. >>> >>> Evan >>> >> That makes sense. In that case I believe >> SelectionDAGLegalize::LegalizeSetCCOperands >> should be

Matthijs Kooijman wrote: > Hi, > > after working with llvm for a while, I'm still a little confused with the > meaning of the 'byval' attribute. From the langref: > > "This indicates that the pointer parameter should really be passed by value to > the function. The attribute implies that a hidden copy of the pointee is made > between the caller and the

Duncan Sands wrote: > Hi, byval means that the parameter setup code for performing a call > copies the struct onto the stack, in an appropriate position relative > to the other call parameters. > > >> I'm particularly confused by the "between the caller and the callee" part. The >> way I see this, the responsibility for the copying should be with either

Rubin, Norman wrote: > I'm trying to install llvm on my windows development box and hit a > problem > I'm using cygwin > cygwin% gcc --version > gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > > I downloaded both the top of tree via svn > I ran ./configure > make > > make[1]: Entering directory `/cygdrive/c/llvm/lib/Support' >

Richard Pennington wrote: > My target doesn't support 64 bit arithmetic, so I'd like to supply > definitions for adde/addc. The problem is I can't seem to figure out the > magic. Here's an example of what I need to generate: > > # two i64s in r5/r6 and r7/r8 > # result in r1/r2, carry in r3 > > # adde > add r2, r6, r8 > cmpltu r3, r2, r6 #

I'm trying to write a backend for a target with no hardware floating point support. I've added a single i32 register class. I'm wanting all floating point operations to be lowered to library function calls. For the most part LLVM seems to get this right. For example define double @div(double %a, double %b) { %result = fdiv double %a, %b ret double %result } is expanded to a

Evan Cheng wrote: > On Jul 1, 2008, at 3:42 PM, Richard Osborne wrote: > > >> Evan Cheng wrote: >> >>> On Jun 25, 2008, at 5:13 AM, Richard Osborne wrote: >>> >>> >>> >>>> Evan Cheng wrote: >>>> >>>> >>>>> On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote:

Evan Cheng wrote: > On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote: > >> I'm trying to write a backend for a target with no hardware floating >> point support. I've added a single i32 register class. I'm wanting all >> floating point operations to be lowered to library function calls. For >> the most part LLVM seems to get this right. For example

Evan Cheng wrote: > On Jun 25, 2008, at 5:13 AM, Richard Osborne wrote: > > >> Evan Cheng wrote: >> >>> On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote: >>> >>> >>>> I'm trying to write a backend for a target with no hardware floating >>>> point support. I've added a single i32 register class. I'm