search for: armtargetmachine

On Tue, Apr 23, 2013 at 10:29:32AM +0400, Anton Korobeynikov wrote: > Hello > > There is not support for big endian ARM at all. I guess he need to change the data layout string in ARMTargetMachine::ARMTargetMachine (ARMTargetMachine.cpp) from "e" to "E" to get big endian output? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~...

> I guess he need to change the data layout string in > ARMTargetMachine::ARMTargetMachine (ARMTargetMachine.cpp) > from "e" to "E" to get big endian output? That would be a start, but I'd expect a significant number of bugs where the backend writers have assumed ARM was little-endian (lib/Target/Mips, which *does* support both, has many more...

...little endian address space. > > I've been snooping around, but can't seem to find where the conversion to a > byte operation is done. Could someone point me in the right direction? > I've figured out my problem. I didn't adjust the data layout description string in ARMTargetMachine.cpp for big endian targets. This brings up another question. clang has its own set of description strings for varying ABIs, etc. Should those strings somehow override in the code generators? -Rich

Hello There is not support for big endian ARM at all. On Tue, Apr 23, 2013 at 9:26 AM, gamma_chen <gamma_chen at yahoo.com.tw> wrote: > The llvm ARM backend is little endian elf output as my examination as > below. Is it support bid endian by other llc options as below? > > llc -filetype=obj -march=arm // little endian > llc -filetype=obj -march=? or -otheroption=? // to

Hi, I've been trying to set up clang/LLVM to compile for big endian ARM and I need a little help. The code generation works for the most part and most of my regression tests pass, but I noticed that code like this extern void g(void); int *p; int main() { if (*p & 0x01000000) g(); } generates ldr r0, [r0] ldrb r0, [r0, #3]

The llvm ARM backend is little endian elf output as my examination as below. Is it support bid endian by other llc options as below? llc  -filetype=obj -march=arm // little endian llc  -filetype=obj -march=? or -otheroption=? // to output big endian Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL:

Dear developers. My question is the same as the title. Is there any way to implement target specific optimizations after instruction selection or later? I cannot find any related document. Please let me know. Thanks in advance. Minwook Ahn -------------- next part -------------- An HTML attachment was scrubbed... URL:

Yes. There are lots of examples of this. For example ARM target has a number of specific optimization passes. See ARMTargetMachine.cpp addPreEmitPass() etc. for examples of how they are added to codegen pass manager. Evan On Jan 19, 2010, at 11:34 PM, minwook Ahn wrote: > Dear developers. > > My question is the same as the title. > Is there any way to implement target specific optimizations after instruction se...

...gt;> >> I've been snooping around, but can't seem to find where the conversion to a >> byte operation is done. Could someone point me in the right direction? >> > > I've figured out my problem. I didn't adjust the data layout description string > in ARMTargetMachine.cpp for big endian targets. > > This brings up another question. clang has its own set of description strings > for varying ABIs, etc. Should those strings somehow override in the code > generators? The current design is that the frontend (if it attaches a TD string) is *required* t...

...t/PowerPC/PPCCodeEmitter.cpp * Parameterized to support JITCodeEmitter and in future ObjectCodeEmitter lib/Target/PowerPC/PPCJITInfo.h lib/Target/PowerPC/PPCJITInfo.cpp * Replaced references to MachineCodeEmitter with JITCodeEmitter. lib/Target/ARM/ARM.h lib/Target/ARM/ARMTargetMachine.h lib/Target/ARM/ARMTargetMachine.cpp lib/Target/ARM/ARMCodeEmitter.cpp * Parameterized to support JITCodeEmitter and in future ObjectCodeEmitter lib/Target/ARM/ARMJITInfo.h lib/Target/ARM/ARMJITInfo.cpp * Replaced references to MachineCodeEmitter with JITCodeEmitter....

While implementing a MachineFunctionPass that runs as part of the ARMTargetMachine::addPreEmitPass(), I've run into a problem. This particular MFP can drastically increase the size (in MachineInstr count) of the MachineFunction that it processes, so much so that there is a real danger of pcrel calls and branches that use immediate offsets to not be sufficient. A naive test c...

...t $17,15,$0 zapnot $16,15,$1 cmpeq $1,$0,$0 beq $0,$BB1_2 #return $BB1_1: #cond_true bis $31,$31,$0 ret $31,($26),1 $BB1_2: #return lda $0,1($31) ret $31,($26),1 ---------------------------------- I have added createCFGSimplificationPass in ARMTargetMachine::addInstSelector to fix this problem. Is this the correct solution? I think that more architectures might benefit... Best Regards, Rafael

...efinitions, other manufacturers are free to > ignore. I think there are several common use cases for these attributes - 1. to mark what ISA a function is compiled for: (i.e. is it a thumb16/thumb32/ARM?) 2. to constrain the generated code to use specific co-processors. At least for case 2, the ARMTargetMachine/ARMSubtarget contains a distinct set of flags which should be output in the file scope section of the attributes For case 1, I don't know how common it is for the same executable to cross thumb boundaries - (given that16bit thumb has limits on register usage etc..) but I suppose its possible....

Dear developers! I’d like to ask you a question concerning the implementation of one algorithm for the generation of energy-efficient code for ARM processors. Unfortunately, the documentation on this subject is incomplete on your site, so could you please explain how to implement my algorithm. Without going into details, I would like to say, that the implementation of this algorithm

...to the ARM back end I'm getting quite a lot of this assertion failure: Pass.cpp:255: llvm::Pass* llvm::PassInfo::createPass() const: Assertion `NormalCtor && "Cannot call createPass on PassInfo without default ctor!"' failed. A simple way to get it is to add two lines to ARMTargetMachine.cpp: #include "llvm/Transforms/Scalar.h" and PM.add(createSinkingPass()); in addInstSelector just before this line: PM.add(createARMISelDag(*this, OptLevel)); Then run anything through the ARM back end, for example: clang -cc1 -triple thumbv7-eabi -O3 -target-cpu cortex-a8 x.c...

...ng around, but can't seem to find where the > >> conversion to a byte operation is done. Could someone point me in > >> the right direction? > >> > > > > I've figured out my problem. I didn't adjust the data layout > > description string in ARMTargetMachine.cpp for big endian targets. > > > > This brings up another question. clang has its own set of > > description strings for varying ABIs, etc. Should those strings > > somehow override in the code generators? > > The current design is that the frontend (if it attaches...

...g. I have used MachineProfileInfo and Profile estimator as dependent passes over my pass. I am sending you the code for my pass. the error says: void llvm::PMTopLevelManager::schedulePass(llvm::Pass*): Assertion `PI && "Expected required passes to be initialized"' failed. In *ARMTargetMachine.cpp, function bool ARMPassConfig::addPreEmitPass() *the following has been added *PassRegistry &Registry=*PassRegistry::getPassRegistry(); initializeARMInstrStatsPass(Registry);* The program is executed with the following command : *clang -march=armv7-a -mfloat-abi=soft -ccc-host-triple arm...

...tionPass was disabled on 2006/09/04. > This causes some problems for architectures that use conditional moves > to implement select (alpha and ARM). For example, on 2006/09/03 a "if > (a) return 0; else return 1;" compiled to > I have added createCFGSimplificationPass in > ARMTargetMachine::addInstSelector to fix this problem. Is this the > correct solution? I think that more architectures might benefit... Please don't do that. Instead, please implement the TargetInstrInfo branch analysis hooks so that the branch folding pass can do this. Given info about branches, the pas...

..., if the default value is known to be "false". I also made the following changes in the patch: 1. In the constructor of MachineFunction, call the version of getSubtargetImpl that takes a Function parameter, so that it gets the Subtarget specific to the Function being compiled. 2. Change ARMTargetMachine::SubtargetMap to be a DenseMap<Function*, unique_ptr<ARMSubtarget>>. This is just a temporary change to ease debugging and should be reverted to a StringMap or changed to another type of map later. On Mon, Nov 17, 2014 at 11:40 AM, Eric Christopher <echristo at gmail.com> wrote:...

...sis(Registry); initializeInstrumentation(Registry); initializeCodeGen(Registry); initializeTarget(Registry); printf("\n%s:%d",__FILE__,__LINE__); fflush(stdout); return new ARMInstrStats(PIL); } } The following changes have been made to the file ARMTargetMachine.cpp in the function bool ARMPassConfig::addPreEmitPass(): bool ARMPassConfig::addPreEmitPass() { if (getARMSubtarget().isThumb2()) { if (!getARMSubtarget().prefers32BitThumb()) PM->add(createThumb2SizeReductionPass()); // Constant island pass work on unbundled instructions....