search for: constantpools

Hello. I'm having problems at instruction selection with my back end with the following basic-block due to a vector add with immediate constant vector (obtained by vectorizing a simple C program doing vector sum map): vector.ph: ; preds = %vector.memcheck50 %.splatinsert = insertelement <8 x i64> undef, i64 %i.07.unr, i32 0

...MCSymbol *Label = + getContext().GetOrCreateSymbol("$cp." + Twine(ConstantPoolCounter++)); As previously mentioned, this sort of label name isn’t portable. Whether ‘$’ is legal isn’t guaranteed, and there’s no assembler-local label prefix. + ConstantPoolMapTy::iterator Cp = ConstantPools.find(Section); Minor detail in various places in the code. Acronyms should be capitalized, so “CP” instead of “Cp”. Even better would be spelled out names if they’re short enough to make sense in the context of the code. +void ARMAsmParser::finishParse() { + for (ConstantPoolMapTy::iterator CpI...

Moving discussion to llvm-commits now that I have a more developed implementation: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131111/195401. html > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of David Peixotto > Sent: Tuesday, November 12, 2013 11:09 AM > To: 'Amara Emerson' >

...viously mentioned, this sort of label name isn't portable. Whether > '$' is legal isn't guaranteed, and there's no assembler-local label > prefix. This was fixed in a later patch by using the CreateTempSymbol() API in MCContext. > + ConstantPoolMapTy::iterator Cp = ConstantPools.find(Section); > > Minor detail in various places in the code. Acronyms should be > capitalized, so "CP" instead of "Cp". Even better would be spelled out > names if they're short enough to make sense in the context of the code. I will clean that up when I reba...

...label name isn't portable. Whether >> '$' is legal isn't guaranteed, and there's no assembler-local label >> prefix. > > This was fixed in a later patch by using the CreateTempSymbol() API in > MCContext. > >> + ConstantPoolMapTy::iterator Cp = ConstantPools.find(Section); >> >> Minor detail in various places in the code. Acronyms should be >> capitalized, so "CP" instead of "Cp". Even better would be spelled out >> names if they're short enough to make sense in the context of the code. > > I will...

Hi Lauro, This is a very tricky problem to resolve. Basically you need a pass just before code emission to find the proper locations for each constant pool. That means you need: 1. Exact size of each instruction. This can be added with a custom instrinfo that specify instruction length for each target instruction. 2. Probably some kind of constantpool pseudo instruction. The pass can then

Hi, after perusing through llc -debug output and stepping through the ARMGenDAGIsel.inc in the debugger, I would greatly like some help in tracking down a failing match to a pattern I specified: First, here is a snippet of a successful match (done in ARM mode) ISEL: Starting pattern match on root node: 0x1e7adf0: i32,ch = load 0x1e4c030, 0x1e78210, 0x1e78310<LD4[ConstantPool]> [ID=10]

I have attached an initial patch that implements the ldr pseudo. It still needs some clean up and more tests, but I would like some feedback on the approach I used and if there are any objections to implementing it this way. Here is my approach: Add a finishParse() callback to the target asm parser This callback is invoked when the parse has finished successfully. It will be used to write out

I'm facing a problem with constant pool in large functions. The LLVM prints constant pool at the beginning of functions. In large functions loads can be far from constant pool. GCC resolves this situations by spreading constants throughtout functions. A C test and the code generated by LLVM and GCC are attached. As you can see in the following error the ldr is too far from constant: $

Is there any way to get llvm to not spill floating point constants to memory but to keep them in registers, i.e. get rid of the constantPool and just generate ConstantFP instructions? Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part

Hi everyone, vmkit requires to know the size of a jitted method before emitting the method. This allows to allocate the correct size for the method. The attached patch creates this functionality when the flag SizedMemoryCode is on. In order to implement this functionality, i had to virtualize some MachineCodeEmitter functions. Is it OK to commit the patch? Thanks, Nicolas --------------

libswfdec/js/jsinterp.h | 1 libswfdec/swfdec_bits.c | 28 +++ libswfdec/swfdec_bits.h | 9 - libswfdec/swfdec_codec_screen.c | 2 libswfdec/swfdec_image.c | 98 ++++-------- libswfdec/swfdec_script.c | 315 ++++++++++++++++++++++++++++++++++++++-- libswfdec/swfdec_swf_decoder.c | 2 libswfdec/swfdec_tag.c | 23 -- 8 files

Hi Evan, Evan Cheng wrote: > 1) How are you computing size of the method being > jitted? I add a new pass with addSimpleCodeEmitter, with the emitter being a SizeEmitter. Since the target calls the emitter with functions such as writeByte, writeWord, etc.... the SizeEmitter class implements these function by incrementing a counter. At the end of the pass, the code size of the

Hi, Two questions. 1) How are you computing size of the method being jitted? 2) Why not simply add the functionality of allocating emission buffer of specific size to MachineCodeEmitter instead? Thanks, Evan On Mar 30, 2008, at 12:05 PM, Nicolas Geoffray wrote: > Hi everyone, > > vmkit requires to know the size of a jitted method before emitting > the method. This allows to

On Apr 1, 2008, at 12:50 AM, Nicolas Geoffray wrote: > Hi Evan, > > Evan Cheng wrote: >> 1) How are you computing size of the method being >> jitted? > > I add a new pass with addSimpleCodeEmitter, with the emitter being a > SizeEmitter. Since the target calls the emitter with functions such as > writeByte, writeWord, etc.... the SizeEmitter class implements these

Evan Cheng wrote: > On Apr 1, 2008, at 12:50 AM, Nicolas Geoffray wrote: > > > That's a hack. :-) It is if you think that code emitter should only be used for actually writing somewhere the data. It is not if you find it another useful utility ;-) > Some targets already have ways to compute the exact > size of a function. See ARM::GetFunctionSize()

Evan Cheng wrote: > > Let's see. ARM has it already. PPC has getNumBytesForInstruction so > you only need to add one to compute function size. Also you only need > to implement it for targets that support JIT right now, which leaves > Alpha and X86. I'm guessing Alpha is using fixed encoding so it should > be pretty easy. Or you can just punt it and let the target

i want to implement gather for v64i32. i wrote following code. def GATHER_256B : I<0x68, MRMSrcMem, (outs VR_2048:$dst), (ins i2048mem:$src), "GATHER_256B\t{$src, $dst|$dst, $src}", [(set VR_2048:$dst, (v64i32 (masked_gather addr:$src)))], IIC_MOV_MEM>, TA; def: Pat<(v64f32 (masked_gather addr:$src)), (GATHER_256B

On Apr 4, 2008, at 11:16 PM, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote: > Evan Cheng wrote: >> >> Let's see. ARM has it already. PPC has getNumBytesForInstruction so >> you only need to add one to compute function size. Also you only need >> to implement it for targets that support JIT right now, which leaves >> Alpha and X86. I'm

Hi David, Thanks for your efforts here. I have a few comments on your patch, although I realise it's still a work in progress. +class ConstantPool { + MCSymbol *Label; + typedef std::vector<const MCExpr*> EntryVecTy; Use a SmallVector here? + MCSymbol *getLabel() {return Label;} + size_t getNumEntries() {return Entries.size();} + const MCExpr *getEntry(size_t Num) {return