Displaying 20 results from an estimated 110 matches for "machinecodeemitters".
Did you mean:
machinecodeemitter
2009 Mar 16
0
[LLVMdev] MachO and ELF Writers/MachineCodeEmitters arehard-codedinto LLVMTargetMachine
> Sorry, I disagree actually the MachineCodeEmitter or the
> 'MachineCodeWritter' does not do any file handling at all. Do look at the
> code for the MachineCodeWritter and you will see it only writes to memory
> and if it reaches the end of the allotted memory I believe higher ordered
> logic reallocates a larget buffer and starts again from scratch. This could
> be
2009 Mar 16
2
[LLVMdev] MachO and ELF Writers/MachineCodeEmitters arehard-codedinto LLVMTargetMachine
On Mon, Mar 16, 2009 at 3:26 AM, Aaron Gray <aaronngray.lists at googlemail.com
> wrote:
> On Sun, Mar 15, 2009 at 10:52 PM, Aaron Gray <
> aaronngray.lists at googlemail.com> wrote:
>
>> I like the idea of a generic MachineCodeWriter, although I prefer the
>>> name 'ObjectFileWriter'...
>>>
>>
>> Thats much more descriptive of
2009 Mar 16
1
[LLVMdev] MachO and ELF Writers/MachineCodeEmitters arehard-codedinto LLVMTargetMachine
> Sorry, I disagree actually the MachineCodeEmitter or the
> 'MachineCodeWritter' does not do any file handling at all. Do look at the
> code for the MachineCodeWritter and you will see it only writes to memory
> and if it reaches the end of the allotted memory I believe higher ordered
> logic reallocates a larget buffer and starts again from scratch. This could
> be
2009 Mar 16
2
[LLVMdev] MachO and ELF Writers/MachineCodeEmittersarehard-codedinto LLVMTargetMachine
>> Sorry, I disagree actually the MachineCodeEmitter or the
>> 'MachineCodeWritter' does not do any file handling at all. Do look at the
>> code for the MachineCodeWritter and you will see it only writes to memory
>> and if it reaches the end of the allotted memory I believe higher ordered
>> logic reallocates a larget buffer and starts again from scratch.
2009 Mar 16
0
[LLVMdev] MachO and ELF Writers/MachineCodeEmitters arehard-codedinto LLVMTargetMachine
On Sun, Mar 15, 2009 at 10:52 PM, Aaron Gray <
aaronngray.lists at googlemail.com> wrote:
> I like the idea of a generic MachineCodeWriter, although I prefer the
>> name 'ObjectFileWriter'...
>>
>
> Thats much more descriptive of the functionality.
>
Sorry, I disagree actually the MachineCodeEmitter or the
'MachineCodeWritter' does not do any file
2009 Feb 28
2
[LLVMdev] Removal of GVStub methods from MachineCodeEmitter, ELFWriter, and MachOWriter
I have done a possible cleanup patch for the MachineCodeEmitter, ELFWriter,
and MachOWriter classes. It removes the two startGVStub(), and
finishGVStub() JIT specific methods.
You may remember the following comments :-
/// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE!
To get rid of these easily turned out to be a semicomplex modification
because of the JITInfo classes dependance on
2009 Mar 15
3
[LLVMdev] MachO and ELF Writers/MachineCodeEmitters arehard-codedinto LLVMTargetMachine
...en be simply re-written to use these generic functions
>instead of the hard-coded MachO and ELF ones.
Okay, this give more flexability and usability.
On Sun, Mar 15, 2009 at 10:39 PM, Aaron Gray
<aaronngray.lists at googlemail.com> wrote:
>> Currently, the MachO and ELF Writers and MachineCodeEmitters are
>> hard-coded into LLVMTargetMachine and llc.
>
> I am also interested in working on this area and interested in writting a
> COFF file backend.
>
>> In other words, the 'object file generation' capabilities of the
>> Common Code Generator are not generic....
2009 Mar 02
0
[LLVMdev] Removal of GVStub methods from MachineCodeEmitter, ELFWriter, and MachOWriter
I'll look at these. First scan looks good. Are you able to run some
tests?
Evan
On Feb 28, 2009, at 9:36 AM, Aaron Gray wrote:
> I have done a possible cleanup patch for the MachineCodeEmitter,
> ELFWriter, and MachOWriter classes. It removes the two
> startGVStub(), and finishGVStub() JIT specific methods.
>
> You may remember the following comments :-
>
>
2006 Feb 27
2
[LLVMdev] Directly generating binary file
Hi!
I'm looking for a way to make the the "llc" tool (or any other tool),
directly produce a binary file for some target.
The TargetMachine class has a method 'addPassesToEmitMachineCode', that's
suitable for that, but that method also requires an instance of
MachineCodeEmitter.
The existing MachineCodeEmitter derived classes are either debug-only
(writing to
2009 Mar 16
2
[LLVMdev] MachO and ELFWriters/MachineCodeEmittersarehard-codedinto LLVMTargetMachine
> Aaron, I mailed in the same mail twice (by mistake), you answered both
> copies. Differently!
>
> In any case, I've re-read what exists. I'm dumping what I understand
> here, so that we can discuss in detail. I'm using MachO as the example
> object format, as the ELF code is totally broken and outdated. Lets
> use the following as the basis for our discussion?
2009 Mar 15
1
[LLVMdev] MachO and ELF Writers/MachineCodeEmitters are hard-codedinto LLVMTargetMachine
> Currently, the MachO and ELF Writers and MachineCodeEmitters are
> hard-coded into LLVMTargetMachine and llc.
I am also interested in working on this area and interested in writting a
COFF file backend.
> In other words, the 'object file generation' capabilities of the
> Common Code Generator are not generic.
I was looking at making a pa...
2009 Mar 15
0
[LLVMdev] MachO and ELF Writers/MachineCodeEmitters are hard-codedinto LLVMTargetMachine
...bject Files the
TargetMachine supports.
llc could then be simply re-written to use these generic functions
instead of the hard-coded MachO and ELF ones.
On Sun, Mar 15, 2009 at 10:39 PM, Aaron Gray
<aaronngray.lists at googlemail.com> wrote:
>> Currently, the MachO and ELF Writers and MachineCodeEmitters are
>> hard-coded into LLVMTargetMachine and llc.
>
> I am also interested in working on this area and interested in writting a
> COFF file backend.
>
>> In other words, the 'object file generation' capabilities of the
>> Common Code Generator are not generic....
2009 Mar 16
0
[LLVMdev] MachO and ELFWriters/MachineCodeEmittersarehard-codedinto LLVMTargetMachine
> I've never looked at the MachO code as I do not have such a platform nor do
> I know the file format.
>
> Could we concentrate on the ELF backend, please.
I don't mind using the ELF backend as our test case, it just seems
that the ELFWriter/ELFCodeEmitter don't even use the
BufferBegin/BufferEnd/CurBufferPtr system exposed by the base
MachineCodeEmitter. There is a big
2008 Apr 01
2
[LLVMdev] Being able to know the jitted code-size before emitting
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
2006 Feb 27
0
[LLVMdev] Directly generating binary file
On Mon, 27 Feb 2006, Vladimir Prus wrote:
> I'm looking for a way to make the the "llc" tool (or any other tool),
> directly produce a binary file for some target.
ok
> The TargetMachine class has a method 'addPassesToEmitMachineCode', that's
> suitable for that, but that method also requires an instance of
> MachineCodeEmitter.
Actually, you probably
2008 Nov 22
2
[LLVMdev] MachineCodeEmitter Patch
Hi,
The following code:
#include<stdio.h>
char bigArray[0x1000000];
int main(int argc, char **argv) {
printf("mem: 0x%x\n", (unsigned) bigArray);
return 0;
}
causes lli to silently fail, even though it compiles correctly with
llc. The reason is that in JITEmitter.cpp only checks to see if
CurBufferPtr == BufferEnd at the beginning of the function and not after
all
2009 Mar 15
2
[LLVMdev] MachO and ELF Writers/MachineCodeEmitters are hard-coded into LLVMTargetMachine
Currently, the MachO and ELF Writers and MachineCodeEmitters are
hard-coded into LLVMTargetMachine and llc.
In other words, the 'object file generation' capabilities of the
Common Code Generator are not generic.
LLVMTargetMachine::addPassesToEmitFile explicitly checks whether the
derived backend TargetMachine implements one of getMachOWriterInfo or...
2008 Dec 08
1
[LLVMdev] MachineCodeEmitter Patch
Thanks. I do not have commit privilege.
Tom
----- Original Message -----
From: "Evan Cheng" <evan.cheng at apple.com>
To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
Sent: Monday, December 8, 2008 5:39:33 PM GMT -05:00 US/Canada Eastern
Subject: Re: [LLVMdev] MachineCodeEmitter Patch
Looks good. Do you have commit privilege?
Evan
On Nov 22, 2008, at
2008 Apr 05
2
[LLVMdev] Being able to know the jitted code-size before emitting
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
2008 Apr 01
0
[LLVMdev] Being able to know the jitted code-size before emitting
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