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