similar to: [LLVMdev] MCStreamer itnerface

Displaying 20 results from an estimated 900 matches similar to: "[LLVMdev] MCStreamer itnerface"

2010 May 04
2
[LLVMdev] MCStreamer itnerface
This is a brain-dump of my thoughts on the MCStreamer interface after several days of digging around trying to get a COFF writer working. All fragments should be associated with a symbol. For assembler components, a unnammed "virtual" symbol can be used when there is no explicit label defined. Section assignment should be the responsiblity of the object imlementing the MCStreamer
2010 May 05
3
[LLVMdev] MCStreamer interface
On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > This is a brain-dump of my thoughts on the MCStreamer interface after several > days of digging around trying to get a COFF writer working. Great! Something that is worth pointing out is that the MCStreamer API is intended to directly reflect what is happening in .s files. We basically want one MCStreamer callback to correspond to one
2010 May 05
0
[LLVMdev] MCStreamer interface
On Wed, May 5, 2010 at 11:15 AM, Chris Lattner <clattner at apple.com> wrote: > On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > ... We basically want one MCStreamer callback to correspond to one > statement in the .s file. This makes it easier to handle from the compiler > standpoint, but is also very important for the llvm-mc assembly parser > itself. > > This
2010 May 05
4
[LLVMdev] MCStreamer interface
On Wed, May 5, 2010 at 1:22 PM, Nathan Jeffords <blunted2night at gmail.com> wrote: > I had a problem with MCStreamer::EmitCommonSymbol > & MCStreamer::EmitLocalCommonSymbol. When I implemented them I assumed this > meant to put those symbols into the .bss segment. This required me to get a > hold of the TLOF from the streamer. I now realize this is wrong after >
2010 May 07
1
[LLVMdev] MCStreamer interface
On 7 May 2010 08:15, Nathan Jeffords <blunted2night at gmail.com> wrote: > > > On Fri, May 7, 2010 at 12:05 AM, Chris Lattner <clattner at apple.com> wrote: > >> >> On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: >> >> Thanks! Funny, I was just preparing a patch to submit for my changes to >> MCSectionCOFF. My changes look to be fairly
2010 May 05
0
[LLVMdev] MCStreamer interface
> > > Global definitions like "int x;" are treated as common to allow > linking buggy programs that forget to use "extern" on declarations. Is this always the behavior, or only when certain options are set? This seems like a violation of the language standard. -------------- next part -------------- An HTML attachment was scrubbed... URL:
2010 May 05
1
[LLVMdev] MCStreamer interface
Re having all fragments associated with some symbol -- this makes sense if you think in high level terms and assume all symbols to be some "objects". All data (fragments) you want to output is associated with some "object" (symbol). However, that's probably too high level thinking for MC interface. High level objects might not directly correspond to object-file level
2010 May 07
0
[LLVMdev] MCStreamer interface
On Fri, May 7, 2010 at 12:05 AM, Chris Lattner <clattner at apple.com> wrote: > > On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: > > Thanks! Funny, I was just preparing a patch to submit for my changes to > MCSectionCOFF. My changes look to be fairly independent of yours, my change > was to deal with COMDAT's. I had dealt with the characteristics flags in the >
2010 May 07
2
[LLVMdev] MCStreamer interface
On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: > Thanks! Funny, I was just preparing a patch to submit for my changes to MCSectionCOFF. My changes look to be fairly independent of yours, my change was to deal with COMDAT's. I had dealt with the characteristics flags in the object writer, but I like this. If you don't mind I would like to merge my changes into this patch and submit
2011 May 30
0
[LLVMdev] how to emit machine code to custom MCStreamer
Hi! I'd like to emit code to a custom MCStreamer instead of e.g. MCELFStreamer. Unfortunately LLVMTargetMachine::addCommonCodeGenPasses is private but I would need it, or even better a method simular to addPassesToEmitFile (e.g. addPassesToEmitCustomMC) taking an MCSreamer would be great. What do you think? -Jochen
2010 May 06
0
[LLVMdev] MCStreamer interface
> > > The logic to handle this has to go somewhere, putting it in the MCStreamer > *implementation* that needs it is the most logical place. We also aim to > implement an assembler, it doesn't make sense to duplicate this logic in the > compiler and the assembler parser. > > Assembly language has often been *the* intermediate form for between compilers and object
2010 May 07
0
[LLVMdev] MCStreamer interface
Thanks! Funny, I was just preparing a patch to submit for my changes to MCSectionCOFF. My changes look to be fairly independent of yours, my change was to deal with COMDAT's. I had dealt with the characteristics flags in the object writer, but I like this. If you don't mind I would like to merge my changes into this patch and submit it. I was just pondering how to deal with the
2010 May 05
0
[LLVMdev] MCStreamer interface
Somewhere I had got it in my head that global variables had static storage class by default. I guess I was wrong. On May 5, 2010 2:45 PM, "Dale Johannesen" <dalej at apple.com> wrote: On May 5, 2010, at 2:32 PMPDT, Nathan Jeffords wrote: >> >> Global definitions like "int x;" are t... Technically yes; the original K&R C book had the one-definition rule
2010 May 05
2
[LLVMdev] MCStreamer interface
On May 5, 2010, at 1:22 PM, Nathan Jeffords wrote: > On Wed, May 5, 2010 at 11:15 AM, Chris Lattner <clattner at apple.com> wrote: > On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > ... We basically want one MCStreamer callback to correspond to one statement in the .s file. This makes it easier to handle from the compiler standpoint, but is also very important for the llvm-mc
2010 May 07
3
[LLVMdev] MCStreamer interface
On Wed, 2010-05-05 at 13:22 -0700, Nathan Jeffords wrote: > > The important point here is that the COFF MCSection needs to > have the right level of semantic information. In fact, > MCSection is the place that I'd start for COFF bringup. > > OK, I see that now. The current isolation > between TargetLoweringObjectFile ->
2010 May 07
0
[LLVMdev] MCStreamer interface
On Wed, May 5, 2010 at 5:53 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 5, 2010, at 5:22 PM, Nathan Jeffords wrote: >> >> The logic to handle this has to go somewhere, putting it in the MCStreamer >> *implementation* that needs it is the most logical place.  We also aim to >> implement an assembler, it doesn't make sense to duplicate this
2016 May 23
0
Using an MCStreamer Directly to produce an object file?
2016 May 21
1
Using an MCStreamer Directly to produce an object file?
llvm-dev, Thanks so much in advance for any help, tips, or advice you may be able to offer me. I'm going to try to avoid the big-picture description of the project I'm working on, and only talk about the parts that I have trouble with / currently need to implement. -- I've been starting by taking the source code from the "llvm-mc" tool, and working that down into a
2010 May 06
2
[LLVMdev] MCStreamer interface
On May 5, 2010, at 5:22 PM, Nathan Jeffords wrote: > > The logic to handle this has to go somewhere, putting it in the MCStreamer *implementation* that needs it is the most logical place. We also aim to implement an assembler, it doesn't make sense to duplicate this logic in the compiler and the assembler parser. > > > Assembly language has often been *the* intermediate
2007 Jan 18
2
subsetting matrix by subscript=0,x silently skips.
(e-mailing to R-bugs is intentional - the web itnerface seems to be down) > a<- cbind(c(1,2), c(3,4)) > a [,1] [,2] [1,] 1 3 [2,] 2 4 > a[cbind(c(2,2), c(2,1))] [1] 4 2 > a[cbind(c(2,3), c(2,1))] Error: subscript out of bounds > a[cbind(c(2,-1), c(2,1))] Error: negative values are not allowed in a matrix subscript > a[cbind(c(2,0), c(2,1))] [1] 4 Am