Rail Shafigulin via llvm-dev
2016-Jan-22 01:25 UTC
[llvm-dev] Is there a reason why MCAsmStreamer class doesn't have its own .h file?
On Thu, Jan 21, 2016 at 5:03 PM, Craig Topper <craig.topper at gmail.com> wrote:> I dont' know why its final. That routine is just a method to force the > current write pointer to a specific alignment. Shouldn't you be changing > the callers to give you the alignment you want or don't want. > > > > -- > ~Craig >It looks like the callers get their information from the data layout object, which in my case is not what I need. Any suggestions? -- Rail Shafigulin Software Engineer Esencia Technologies -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160121/8e5247ab/attachment.html>
Craig Topper via llvm-dev
2016-Jan-22 06:07 UTC
[llvm-dev] Is there a reason why MCAsmStreamer class doesn't have its own .h file?
At least one of the callers would be from the .align directive which I assume you wouldn't want to overload. Where does it come from DataLayout? AsmStreamer is used for assembling from text and I wouldn't expect that to use DataLayout. Or is it used for inline assembly? On Thu, Jan 21, 2016 at 5:25 PM, Rail Shafigulin <rail at esenciatech.com> wrote:> > > On Thu, Jan 21, 2016 at 5:03 PM, Craig Topper <craig.topper at gmail.com> > wrote: > >> I dont' know why its final. That routine is just a method to force the >> current write pointer to a specific alignment. Shouldn't you be changing >> the callers to give you the alignment you want or don't want. >> >> >> >> -- >> ~Craig >> > > It looks like the callers get their information from the data layout > object, which in my case is not what I need. Any suggestions? > > -- > Rail Shafigulin > Software Engineer > Esencia Technologies >-- ~Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160121/59e88585/attachment.html>
Martin J. O'Riordan via llvm-dev
2016-Jan-22 13:04 UTC
[llvm-dev] Is there a reason why MCAsmStreamer class doesn't have its own .h file?
Hi Craig and Rail, At Movidius, we have had to make a few changes to ‘MCAsmStreamer’ to support our assembler which is not ‘gas’ compliant. Earlier versions of LLVM (3.1 and 3.2) did have a separate header for ‘MCAsmStreamer’, and we had previously sub-classed this. The following are modifications that we have had to make because although ‘MCAsmStreamer’ does most of what we need, there are some things that we need to do differently, and if this was available to be sub-classed, then these modifications would be more logical and not require altering the target independent code. · ‘MCAsmStream::EmitAssignment’ has been changed to accommodate our different syntax for ‘.alias’ directives. · ‘MCAsmStream::EmitBytes’ has been changed so that multiple lines of ‘.byte’ directives are emitted to avoid a line-length buffer limitation in our assembler when very large numbers of bytes are to be emitted. · ‘MCAsmStream::EmitFill’ has been changed to accommodate our different syntax for ‘.fill’ directives. These are quite simple changes, and since ‘MCAsmStreamer’ already does everything else the way we need it, it does not make sense for us to have a completely new alternative implementation of ‘MCStreamer’ which effectively clones what this class already does (and it would make it harder for us to mirror changes between releases). All of these methods are already polymorphic, so overriding the implementation in ‘MCAsmStreamer’ would be the best solution for our compiler. Thanks, MartinO From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Craig Topper via llvm-dev Sent: 22 January 2016 6:08 To: Rail Shafigulin Cc: llvm-dev Subject: Re: [llvm-dev] Is there a reason why MCAsmStreamer class doesn't have its own .h file? At least one of the callers would be from the .align directive which I assume you wouldn't want to overload. Where does it come from DataLayout? AsmStreamer is used for assembling from text and I wouldn't expect that to use DataLayout. Or is it used for inline assembly? On Thu, Jan 21, 2016 at 5:25 PM, Rail Shafigulin <rail at esenciatech.com> wrote: On Thu, Jan 21, 2016 at 5:03 PM, Craig Topper <craig.topper at gmail.com> wrote: I dont' know why its final. That routine is just a method to force the current write pointer to a specific alignment. Shouldn't you be changing the callers to give you the alignment you want or don't want. -- ~Craig It looks like the callers get their information from the data layout object, which in my case is not what I need. Any suggestions? -- Rail Shafigulin Software Engineer Esencia Technologies -- ~Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160122/78c8fd03/attachment.html>
Rail Shafigulin via llvm-dev
2016-Jan-22 19:25 UTC
[llvm-dev] Is there a reason why MCAsmStreamer class doesn't have its own .h file?
On Thu, Jan 21, 2016 at 10:07 PM, Craig Topper <craig.topper at gmail.com> wrote:> At least one of the callers would be from the .align directive which I > assume you wouldn't want to overload. Where does it come from DataLayout? > AsmStreamer is used for assembling from text and I wouldn't expect that to > use DataLayout. >I made that assumption based on a very cursory look through the code. Didn't have the time to study it thoroughly. Sorry if this created any confusion. Or is it used for inline assembly?> > -- > ~Craig >-- Rail Shafigulin Software Engineer Esencia Technologies -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160122/32b2c4fa/attachment.html>
Possibly Parallel Threads
- Is there a reason why MCAsmStreamer class doesn't have its own .h file?
- Is there a reason why MCAsmStreamer class doesn't have its own .h file?
- Is there a reason why MCAsmStreamer class doesn't have its own .h file?
- [LLVMdev] AsmPrinter vs. MCAsmStreamer
- [LLVMdev] MCAsmStreamer: format symbol attributes consistently