search for: mfc1

I am compiling the following code for the MIPS architecture: unsigned char trunc(float f) { return (unsigned char) f; } and it produces the following assembly (directives removed for convenience: trunc: trunc.w.s $f0, $f12 mfc1 $2, $f0 jr $ra nop However, this does not seem to produce the correct output for negative numbers. When I run the following code, I get -1 instead of 255 (which is produced by compiling natively with gcc). int trunc(float c); int main() { printf("%d\n", trunc(-1.0)); } I...

I'm trying to just emit simple inline assembler (no constraints, inputs, etc.) Can anyone point me to an example of this..? This is corresponding to: __asm__ ("mfc1 $4,$f12"); This is what I tried but it's not correct. std::vector<llvm::Type *> AsmArgTypes; llvm::FunctionType *AsmFTy = llvm::FunctionType::get(Type::getVoidTy(FStub->getContext()), AsmArgTypes, false); llvm::InlineAsm *IA...

...t;> > unsigned char trunc(float f) { >> > return (unsigned char) f; >> > } >> > >> > and it produces the following assembly (directives removed for >> convenience: >> > trunc: >> > trunc.w.s $f0, $f12 >> > mfc1 $2, $f0 >> > jr $ra >> > nop >> > >> > However, this does not seem to produce the correct output for negative >> > numbers. When I run the following code, I get -1 instead of 255 (which >> is >> > produced by compiling native...

...d: float double float, double float, float double, double double, float .section .mips16.call.fp.fpff,"ax", at progbits .align 2 .set nomips16 .set nomicromips .ent __call_stub_fp_fpff .type __call_stub_fp_fpff, @function __call_stub_fp_fpff: mtc1 $4,$f12 move $18,$31 jal fpff mfc1 $2,$f0 jr $18 .size __call_stub_fp_fpff, .-__call_stub_fp_fpff .end __call_stub_fp_fpff On 04/24/2013 04:25 PM, Rafael Espíndola wrote: >> We also wanted the stubs to be real functions to llvm. That allows them to >> participate properly >> in optimization of various levels...

On 01/28/2014 06:29 PM, Eric Christopher wrote: > Uhhhh... > > -eric > > On Tue, Jan 28, 2014 at 4:56 PM, reed kotler <rkotler at mips.com> wrote: >> I would like to make the following member of AsmPrinter be protected >> >> >> void EmitInlineAsm(StringRef Str, const MDNode *LocMDNode = 0, >> InlineAsm::AsmDialect

...perability with mips32. You get the following looking code from gcc -mips16: # Stub function for foovf (float) .section .mips16.fn.foovf,"ax", at progbits .align 2 .set nomips16 .set nomicromips .ent __fn_stub_foovf .type __fn_stub_foovf, @function __fn_stub_foovf: la $25,foovf mfc1 $4,$f12 jr $25 .end __fn_stub_foovf .text $__fn_local_foovf = foovf Not being sure about the restriction of section to just "name", well docs can be wrong and not match the code, I Googled for this: http://stackoverflow.com/questions/6252812/what-does-the-aw-flag-in-the-section-at...

> It is exactly intended to handle section names as what they are -- > section names. The only reason it works with GCC is because it writes an > assembler stream. +1 Reed, this fails in gcc if you do LTO, no? > Joerg Cheers, Rafael

...e intention is that as code is re-compiled, >> O32+fpxx will replace O32 and we will end up the mode requirements being >> either 'FR=1' or "don't care". >> > >> > In case you're curious, the fpxx restrictions are: >> > * Use of mtc1, mfc1, lwc1, and swc1 on the upper 32-bits of a double >> precision value is not permitted. >> > * Some callee-saved registers are also treated as caller-saved. >> > >> >> Well, this is definitely ABI breaking, so effectively a new ABI is what I >> meant. >&gt...

On Wed, Jun 18, 2014 at 2:03 AM, Matheus Almeida <Matheus.Almeida at imgtec.com> wrote: >> Why Imagination Technologies do not offer the latest MIPS ABI document download link just like the ISA docs? > It's something we're considering to do and the documents should be available at some point in the [hopefully] not too distant future. > >> then why GCC disagree with

...me (because they conflict with eachother). The intention is that as code is re-compiled, O32+fpxx will replace O32 and we will end up the mode requirements being either 'FR=1' or "don't care". > > In case you're curious, the fpxx restrictions are: > * Use of mtc1, mfc1, lwc1, and swc1 on the upper 32-bits of a double precision value is not permitted. > * Some callee-saved registers are also treated as caller-saved. > Well, this is definitely ABI breaking, so effectively a new ABI is what I meant. Curious why an extension to o32 for this and not, for examp...

> We also wanted the stubs to be real functions to llvm. That allows them to > participate properly > in optimization of various levels (including LTO). They can even be inlined. > There are other > planned optimizations that would not work if they were not legitimate > functions. I am not saying that the functions should not exist in the IL, just that they should not be inline

On 04/24/2013 03:47 PM, Rafael Espíndola wrote: > On 24 April 2013 18:30, reed kotler <rkotler at mips.com> wrote: >> There are a lot of issues. >> >> For one, the function I'm compiling is a mips16 function but the stubs being >> created are mips32 functions. >> > This looks similar to thumb x 32 bit arm. Wouldn't a similar solution > work for