similar to: [LLVMdev] [llvm] r210424 - Revert "Do materialize for floating point"

Jim/Tim/Renato, A few days ago (has it been weeks now?) we discussed a codegen problem on armv4t having to do with lo->lo register copies. I'd like to start that discussion again, this time with a patch. A brief summary of the problem for folks who didn't catch the discussion earlier, and those like me who forget what they ate for breakfast: ;] The mov instruction on armv4t

I start my porting for picoblaze,the soft cpu for fpga ,which is designed by XILINX from MSP430 porting . After some day's work , somethinig looks good , for it can generate for some simple C program: eg : int f1(int a) { return a+1; } but it failed with this : char f() { char a; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++;

This code or subtle variations of it appears in multiple targets. It tries to convert from a register to a register class using getRegClass, but getRegClass is really supposed to take a register class enum value and get the register class object for it. It doesn't convert a register to a class. In fact there's not always a single or canonical class for a given register. What is the right

Hi, The PHI elimination pass calls the function copyRegToReg for copy placement and then later tries to setkill to the temporary virtual register used in copy placement. For this setkill action it looks only in one instruction (last instruction for copyRegToReg) for virtual register with no use. My target has only one register and I can't do copyRegToReg in one instruction only. So I

Why do these two guys take a pointer to the basic block, whereas all other BuildMI functions take a reference? They are not checking for null or anything and I didn't see any potential declaration conflicts. Am I missing something? Is there a reason for this? inline MachineInstrBuilder BuildMI(MachineBasicBlock *BB, DebugLoc DL,

On Fri, 4 Jun 2004, Vladimir Prus wrote: > Ok, I'm now trying to write instruction selector and have some questions > > 1. The MachineInstrBuilder has methods to add register operand and immediate > operand. However, what would be really nice is a method to add Value*. So, I > would write: > > BuildMI(*BB, NM::add, 1).add(I.getOperand(0), I.getOperand(1)); > >

Hi Bill, I am using the following version of BuildMI : MachineInstrBuilder BuildMI(MachineFunction &MF, const TargetInstrDesc &TID, unsigned DestReg) I do the following : void createInstrs(std::vector<MachineInstr *>& ilist) { Machine Instr *mi; mi = BuildMI(MF, someTID, somereg);

Chris Lattner wrote: > > 1. The MachineInstrBuilder has methods to add register operand and > > immediate operand. However, what would be really nice is a method to add > > Value*. So, I would write: > > > > BuildMI(*BB, NM::add, 1).add(I.getOperand(0), I.getOperand(1)); > > > > and depending on whether the passed Value* is contant or instruction,

Okay, we're doing a bit of system revamping at my work since our last file server crashed and burned in a horrible tragic failure (hard disk died). Anyways, we've stepped it up a notch with some nice hardware and the fileserver will be running linux (Redhat 9.0 currently). Anyways, I'm currently running into an issue. (I'm using samba 2.2.7a-8.9.0 for reference). Anyways,

When trying to display and do anything with a variable of type IntrinsicInst, gdb thinks that it's an incomplete type and kind find any member functions or even display the class. (gdb) list 1337 1332 1333 // Finish off the call including any return values. 1334 return finishCall(CLI, RetVT, NumBytes); 1335 } 1336 1337 bool MipsFastISel::fastLowerIntrinsicCall(const

I'm happy to send you my patch as it stands today. It's not cleaned up yet all or tested thoroughtly but you can look at what I'm doing and maybe suggest some alternate paths and if it's not a matter of redoing everything, I would consider making some changes. Here is a sample stub: Consider this line of code: extern float fpff(float); We have no idea if this is a mips16 or

(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. In any case, the reason this produces the debugging experience you're seeing is that LLVM (& GCC, for that matter) assumes that if your class

Hi all, There's been a recent bootstrap failure that might be covered up because of another failure. I just wanted to point this out so that people can take a look: -bw Here's the failure from our buildbot: Assertion failed: (DestReg == VirtReg && "Unknown load situation!"), function RewriteMBB, file /Volumes/Sandbox/Buildbot/llvm/build.llvm-

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

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.

On Mon, Jun 23, 2014 at 2:45 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: >> There are a lot of MIPS ABIs. > > Yes, and we've discovered that there seem to be incompatible extensions to some of these ABI's too. :) > >> I'm pretty sure Imagination Technologies working up a new abi right now. > > Not exactly. We're not working on any

> So in summary, each step is ABI compatible with the previous step. The linker will ensure that the end-user doesn't try to do the second step before the first step is finished since it will refuse to link a binary that contains both O32 and O32+fp64. It will produce an O32 binary given a combination of O32+fpxx, and similarly a O32+fp64 binary given a combination O32+fpxx and O32+fp64.

Hi, Paul Curtis wrote: > If you read the Arm Architecture document for ARMv5, it states for MUL: > > "Operand restriction: Specifying the same register for <Rd> and <Rm> was > previously described as producing UNPREDICTABLE results. There is no > restriction in ARMv6, and it is believed all relevant ARMv4 and ARMv5 > implementations do not require this

Hi, > I am using a cross compiler to compiler for the arm5 architecture. For this > architecture it is not allowed that a destination register is also used as source > register. > In 2007 a patch was discussed at the mailing list, however my compiler still is > producing this result. Does anyone know if this patch is actually applied? > > * I use the following arguments:

Hi, I am using a cross compiler to compiler for the arm5 architecture. For this architecture it is not allowed that a destination register is also used as source register. In 2007 a patch was discussed at the mailing list, however my compiler still is producing this result. Does anyone know if this patch is actually applied? * I use the following arguments: llvm-gcc -mfpu=vfp -mlittle-endian