similar to: [LLVMdev] eflags and other

Attached are the promised patches for the below proposed change. Cheers, Jack ________________________________________ From: Carter, Jack Sent: Tuesday, December 11, 2012 1:33 PM To: Jim Grosbach Cc: Rafael Espíndola; List Subject: RE: [LLVMdev] [MC] [llvm-mc] Getting target specific information to <target>ELFObjectWriter Jim, You are correct: MipsSubtarget. For llvm-mc we have a

Jim, You are correct: MipsSubtarget. For llvm-mc we have a straight MCSubtargetInfo object. For llc we get a MipsSubtarget object which derives from MipsGenSubtargetInfo which derives from TargetSubtargetInfo which derives from MCSubtargetInfo. The patch I hope to send out for review will do this: Add a new data member to MCSubtargetInfo base class. It will be a set of integers that is used or

On 04/01/2013 12:31 PM, Chandler Carruth wrote: > On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com > <mailto:nrotem at apple.com>> wrote: > > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if > the attributes changed). Do you have another solution in mind ?

Eli, Yes, SubtargetInfo is more of a container of convenience since it is available to all the assemblers. Working with the current framework it seemed the least disruptive. I'll describe the problem again. The Mips ABI for better or worse, uses the ELF headers e_flags extensively. The most pressing issue is the need to post the relocation model such as PIC, CPIC or non-shared. The object

On Dec 10, 2012, at 1:15 PM, "Carter, Jack" <jcarter at mips.com> wrote: > Here are some examples using the gnu assembler reacting to the same input file with different commandline options. > > These are using the GCC assembler on hello.c > // abi o32, arch mips32r2, relocation model pic+cpic > mips-linux-gnu-as -mips32r2 -EL -KPIC -o hello_gas.o hello_gas.s >

On Wed, Dec 10, 2014 at 5:53 PM, Pierre Moreau <pierre.morrow at free.fr> wrote: > (This is a v3 of patch "drm/nouveau/fb/nv50: Add PFB writes") > > This fix a GPU lockup on 9400M (NVAC) when using acceleration, see > https://bugs.freedesktop.org/show_bug.cgi?id=27501 > > v2: > - Move code to subdev/fb/nv50.c as suggested by Roy Spliet; > - Remove arbitrary

Hi Shankar, > Does LLVM emit rel/rela relocations with ARM ? I believe we emit .rel for (32-bit) ARM. Hard-coded in ARMELFObjectWriter.cpp (“HasRelocationAddend”). It seems to be what most toolchains have settled on. AArch64 is .rela always in LLVM, in case it matters. > Any tests ? Well there are tests of what we do, but obviously not of the full scope of functionality permitted by the

Looks like the bug here is that the InlineAsm parser and the ARM code emitter point to two different TargetSubtargetInfo instances. The attached patch corrects the issue, but is incomplete. For starters, how can I remove that const_cast? Also, the patch does not restore the TargetSubtargetInfo to its original state. So if you changed from Thumb to ARM mode, but not back to Thumb, the code

Done, thanks. And added a code review here: http://llvm-reviews.chandlerc.com/D2255 -Greg On Fri, Nov 22, 2013 at 8:48 AM, Amara Emerson <amara.emerson at arm.com> wrote: > Hi Greg, > > Can you post any patches to the commits list, it'll have a better chance of > some of us seeing it and taking a look there. > > Cheers, > Amara > > -----Original

Some stuff did not get pasted in properly. static MachineBasicBlock* ExpandCondMov(MachineInstr *MI, MachineBasicBlock *BB, DebugLoc dl, const MipsSubtarget *Subtarget, const TargetInstrInfo *TII, bool isFPCmp, unsigned Opc) { //

>> Here's the line of thought that I'd like people to start with: >> * Triples don't describe the target. They look like they should, but they >> don't. They're really just arbitrary strings. > >Triples are used as a starting point, but no more. I disagree with this but for now let's assume it's true. The starting point is incorrect because

I have been working on getting ELF object file writing working for the MBlaze backend. Currently, each supported backend calls ELFObjectWriter::createELFObjectWriter from within the backend's TargetAsmBackend::createObjectWriter method. The createELFObjectWriter method then creates a new backend specific ELFObjectWriter class (either X86ELFObjectWriter or ARMELFObjectWriter) by decoding a

+llvmdev On Fri, Nov 12, 2010 at 7:57 AM, Jim Grosbach <grosbach at apple.com> wrote: > > On Nov 10, 2010, at 9:57 AM, Jason Kim wrote: > >> Refactoring the x86 dependent code from ELFObjectWriter class has >> repercussions among several (conflicting) axes of consideration, >> >> 1. namespace pollution - minimize pollution of the llvm:  namespace >> 2.

On Fri, Dec 14, 2012 at 1:03 PM, Carter, Jack <jcarter at mips.com> wrote: > Eli, > > This is the kind of feedback I want. I believe I have to add to the base class so it should be generally useful. I can see string being better for the value. I still am enamoured with an enumeration for the tab though: int->string. How would that be a limitation? > I guess that's fine,

Hi list! Sometimes I need to make boot floppies for an i386 based Linux router. Just for interest, I tried to use syslinux together with my iMac G4 (PPC) with Yellow Dog Linux to create the floppy. I know that this is generally difficult because it requires cross- compiler and cross-assembler. Nevertheless, I tried it because I only needed the disk installer, the loader binaries for i386

Hi Jack, Everything should be already using the sized Emit* routines directly rather than outputting individual bytes of larger entities piecemeal. Have you found that not to be the case? The Emit* routines handle endianness for you, so you shouldn't have to do much beyond that. For example, here's the EmitInvValue() implementation that underlies things and does the endianness transform:

On 31 July 2015 at 21:10, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > This turns out to be very difficult to fix since the majority of the Mips > target is using Triple::mips and Triple::mips64 to make assumptions about > the architecture (e.g. are registers 64 bit?) or the ABI (Triple::mips > implies O32, Triple::mips64 implies N64 or, in cases where this has been

On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote: > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if the > attributes changed). Do you have another solution in mind ? I don't really understand this. TargetMachine and TTI may be quite expensive to initialize. Doing so for

Proposal for ELF text and data big endian support for direct object generation Unless I am mistaken, currently big endian support in the MC layer for ELF direct object generation is limited to ELF headers and tables like relocations. Text and data section contents are still generated as individual bytes. It looks as if the effort was started, but never completed. The proposal is to extend the

Here are some examples using the gnu assembler reacting to the same input file with different commandline options. These are using the GCC assembler on hello.c // abi o32, arch mips32r2, relocation model pic+cpic mips-linux-gnu-as -mips32r2 -EL -KPIC -o hello_gas.o hello_gas.s e_flags 0x70001007 EF_MIPS_NOREORDER EF_MIPS_PIC EF_MIPS_CPIC E_MIPS_ABI_O32 EF_MIPS_ARCH_32R2 // abi