similar to: Introducing an Alignment object in LLVM

Woah this is a good idea. I'd ask that alignment come in different bit sizes and endienesses so that we can add an alignment type to ELF types. I would love to review this and add it to llvm-objcopy. We have special functions to handle all of these 'zero' cases. Several other bits of code I've seen/written have to find maximum alignment and I'd imagine the mistake of not

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 --------------

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

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

Hi, right now many classes have comments that don't show up in Doxygen. Say, MachineConstantPool.h has a big file-level comment, but it does not show up when looking at the generated docs for MachineConstantPool. Are patches moving file comments to appear before relevant classes welcome? - Volodya

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

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

On Apr 4, 2008, at 5:50 AM, Nicolas Geoffray wrote: > 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 ;-) Except it's pretty slow at it. :-)

Hi Evan, Evan Cheng wrote: > > I don't think the duplication is going to be top much of a problem. If > it is, I'll bug you about refactoring. :) > > I don't mean to show how lazy I can be, but I also need to know the size of the exception table emitted in memory (JITDwarfEmitter.cpp). Reviewing it a little, I can not see how things won't be duplicated.

Today I updated to trunk the toolchain for my work developing on Cortex-M4F. I was super excited to see three commits by Tim Northover that actually attempt to improve the machine code generation for my target, or any ARM target for that matter (as opposed to other important work on compiler correctness or architectural elegance or formatting comment white-space, I mean). Is he alone or are

In ARM, the conventional way of setting a register to a 32 bit constant is to use a load: --------------------------------- str: .asciz "Hello World" .text main: ... ldr r0, .L3 .... .L3: .word str ----------------------------------- To implement this, LowerGlobalAddress must add an element to the constant pool (.L3 in the example). How can I implement this?

Hi Gary, On 3 December 2013 22:01, Gary Fuehrer <gfuehrer at defiant-tech.com> wrote: > The subject of two of his commits dealt with substituting MOVW/MOVT pairs > for an LDR and a lit-pool. Isn't this what MachineConstantPool and > ARMConstantIslandPass was all about? Both are essential components to using lit-pools: the MachineConstantPool is just LLVM's underlying

Dear Mr. Northover, Thank you for the quick reply. You are correct about the address-mode operands :) . I guess an important detail left out was that the basic block (call it A) that wants to calculate the address of the target stationary trampoline basic block (call it B) will be moved around in memory during run-time. Our earlier solution, before the feature was implemented to move around (A)

I had some problems adding the address of a jump table to the constant pool. The problem is that the address of a jump table is not a GlobalValue.Currently I decided to expand BRIND so that I can work on simpler problems :-) A small brain dump on the issue: GlobalValues are currently used to represent functions and global variables. Maybe we could also use then for anything that will have a label

Hi everyone, Here's a patch that enables exception handling when jitting. I've copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may need to factorize it, but the functionality is there and I'm very happy with it :) lli should now be able to execute the output from llvm-gcc when using exceptions (the UnwindInst instruction is not involved in this patch). Just add the

On Apr 7, 2008, at 3:02 AM, Nicolas Geoffray wrote: > Hi Evan, > > Evan Cheng wrote: >> >> I don't think the duplication is going to be top much of a problem. >> If >> it is, I'll bug you about refactoring. :) >> >> > > I don't mean to show how lazy I can be, but I also need to know the > size > of the exception table

It looks like the CyberPower Cyber Power Systems CP685AVR supported by usbhid-ups has a favorable device dump linked to the Devices Dumps Library page here: http://networkupstools.org/ddl/Cyber_Power_Systems/CP685AVR.html However, it is not listed anywhere on the Hardware Compatibility List (HCL) page here: http://networkupstools.org/stable-hcl.html This appears to be an omission on the HCL

Dear all, Here's a new patch with Evan's comments (thx Evan!) and some cleanups. Now the (duplicated) exception handling code is in a new file: lib/ExecutionEngine/JIT/JITDwarfEmitter. This patch should work on linux/x86 and linux/ppc (tested). Nicolas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jit-exceptions.patch URL: