search for: isthumb

...@ class MCELFStreamer : public MCObjectStreamer { public: MCELFStreamer(MCContext &Context, MCAsmBackend &TAB, raw_ostream &OS, MCCodeEmitter *Emitter) - : MCObjectStreamer(Context, TAB, OS, Emitter) {} + : MCObjectStreamer(Context, TAB, OS, Emitter), + IsThumb(false), MappingSymbolCounter(0) {} MCELFStreamer(MCContext &Context, MCAsmBackend &TAB, raw_ostream &OS, MCCodeEmitter *Emitter, MCAssembler *Assembler) - : MCObjectStreamer(Context, TAB, OS, Emitter, Assembler) {} + : MCObjectStreamer(Context...

Attached is an example of how to reproduce the issue. It uses a C file that happens to has a bunch of switch statements which are encoded as jump tables, giving us data-in-code. Usage: To build object files with clang via the -integrated-as versus via GCC: $ export NDK_DIR=<my_ndk_dir> $ export LLVM_DIR=<my_llvm_bin_dir> $ make To test that the generated objects contain the same

...d(); where File::iterator is some type of iterator over Atom. As for serialization. Each atom can have its own serialize/unserialize function for both the Native format and YAML. This would also change ContentType to not contain so many format specific values. It would also allow us to get rid of isThumb as a DefinedAtom level attribute. - Michael Spencer

...ar functionality. If we added a generic uint32_t DefinedAtom::flags() method, I would be concerned that lld porters would be quick to just use the bits for whatever they need and not see if the Atom model needs expanding. An example of something I added (but am not happy with) is DefinedAtom::isThumb(). This is something only applicable to ARM (and only if you care about interop of thumb and arm code). Given that the Reference::Kind field is already platform specific, I'm leaning towards saying that the way to add platform specific atom attributes is to add a Reference with no target to...

...tionality. If we added a generic uint32_t DefinedAtom::flags() method, I would be concerned that lld porters would be quick to just use the bits for whatever they need and not see if the Atom model needs expanding. > > An example of something I added (but am not happy with) is DefinedAtom::isThumb(). This is something only applicable to ARM (and only if you care about interop of thumb and arm code). > > Given that the Reference::Kind field is already platform specific, I'm leaning towards saying that the way to add platform specific atom attributes is to add a Reference with no ta...

...not sure if the Arm code generators are doing this at all. > > Tia for any input. In terms of the instruction descriptions, ARM/Thumb basically has both instruction descriptions embedded into the same set of .td files, and all the instructions are marked with a predicate, either [IsARM] or [IsThumb]. Depending on the computed target, the compiler knows which kind of instructions generate, and the assembler knows how to switch where appropriate. There isn't really anything tricky here. The one key missing bit from what you're describing is that we don't have support for switching...

.... If we added a generic uint32_t DefinedAtom::flags() method, I would be concerned that lld porters would be quick to just use the bits for whatever they need and not see if the Atom model needs expanding. >> >> An example of something I added (but am not happy with) is DefinedAtom::isThumb(). This is something only applicable to ARM (and only if you care about interop of thumb and arm code). >> >> Given that the Reference::Kind field is already platform specific, I'm leaning towards saying that the way to add platform specific atom attributes is to add a Reference w...

Hi, As a first step to port the LLVM chain on an in-house big-endian processor, I'm integrating the native assembler as a new '-assemble -arch=' in llvm-mc. All work quite well, I have a correct output ELF format except that generated code is little-endian. I've understood that the endianess of the LLVM chain is controlled by the DataLayout class, but it appear to me that llvm-mc

We are starting to look at the mips16 and micro mips ports. There are various design issues that people may have some good input on. Especially in how to structure the TD files and other optimizer issues. Mips16 is sort of like thumb and Micro Mips like thumb2 as far as I understand. Mips16 or Micro Mips can live inside of either MIPS32 or MIPS64. In gcc, it's possible using attributes to

On 8 March 2014 00:53, Owen Anderson <resistor at mac.com> wrote: > ISDOpcodes.h contains what documentation there is on the semantics of each > opcode. And TargetOpcodes.h for a few of the post-ISel ones (mostly they're in MachineInstr form, but you'll see them with -view-sched-dags, and occasionally before). Tim.

...look at (from the build directory) lib/Target/ARM/ARMGenDAGISel.inc, I see: /*56478*/ /*SwitchOpcode*/ 13, TARGET_VAL(ISD::GlobalAddress),// ->56494 /*56481*/ OPC_RecordNode, // #0 = $src /*56482*/ OPC_CheckType, MVT::i32, /*56484*/ OPC_CheckPatternPredicate, 4, // (!Subtarget->isThumb()) /*56486*/ OPC_MorphNodeTo, TARGET_VAL(ARM::MOVi32imm), 0, 1/*#VTs*/, MVT::i32, 1/*#Ops*/, 0, // Src: (globaladdr:i32):$src - Complexity = 3 // Dst: (MOVi32imm:i32 (globaladdr:i32):$src) The first lines are fairly unimportant, but the last two sh...

Thanks for the reply Nick. 1) Is there a way to validate that the input file is of a valid format, thats defined by the YAML Reader ? > Do you mean different than if the yaml reader accepts it? Tons of > files will be valid yaml syntactically. It is the semantic level > checking that is hard, and that is what YAML I/O does. > Yes, if the YAML reader accepts it and figures out that

On Oct 30, 2012, at 7:12 AM, Shankar Easwaran wrote: > Hi Nick, > > I had a few questions :- > > 1) Is there a way to validate that the input file is of a valid format, thats defined by the YAML Reader ? Do you mean different than if the yaml reader accepts it? Tons of files will be valid yaml syntactically. It is the semantic level checking that is hard, and that is what

...m/tools/clang/lib/Basic/Targets.cpp:5309:24: error: 'PK_M' is not a member of 'llvm::ARM' if (ArchProfile == llvm::ARM::PK_M) { ^ /export2/src/llvm-trunk/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'bool {anonymous}::ARMTargetInfo::isThumb() const': /export2/src/llvm-trunk/llvm/tools/clang/lib/Basic/Targets.cpp:5322:24: error: 'IK_THUMB' is not a member of 'llvm::ARM' return (ArchISA == llvm::ARM::IK_THUMB); ^ /export2/src/llvm-trunk/llvm/tools/clang/lib/Basic/Targets.cpp: In member...