search for: mtc1

...etValueAPF().bitcastToAPInt().getZExtValue(); > - if (VT == MVT::f32) { > - const TargetRegisterClass *RC = &Mips::FGR32RegClass; > - unsigned DestReg = createResultReg(RC); > - unsigned TempReg = Materialize32BitInt(Imm, &Mips::GPR32RegClass); > - EmitInst(Mips::MTC1, DestReg).addReg(TempReg); > - return DestReg; > - } else if (VT == MVT::f64) { > - const TargetRegisterClass *RC = &Mips::AFGR64RegClass; > - unsigned DestReg = createResultReg(RC); > - unsigned TempReg1 = Materialize32BitInt(Imm >> 32, &Mips::GPR32RegClas...

...s of the form below need to be remapped: 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 >&...

...ame time (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...

...get this group to show up in the list. I do get some interesting messages in the log files though. Here's the one associated with my computer: [2003/06/16 16:00:07, 0] smbd/password.c:domain_client_validate(1556) domain_client_validate: could not fetch trust account password for domain MTC1 --------- the smbd.log file issues the following failure: 2003/06/16 16:00:07, 0] smbd/oplock_linux.c:linux_init_kernel_oplocks(287) Failed to setup RT_SIGNAL_LEASE handler ------- Anyways, if anyone can point me in the right direction, I'd appreciate it. I'm apprehensive in actu...

...r). 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. &...

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

> 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