llvm dev - Jan 2016 - 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>

It appears that the intended mechanism for extending the AsmStreamer is
through the MCTargetStreamer interface:
http://llvm.org/docs/doxygen/html/classllvm_1_1MCTargetStreamer.html

Obviously, that may not be enough flexibility for certain out of tree
targets. EmitBytes is pretty similar for all in-tree targets currently. If
you can make your target's assembly work through that interface, it'll
probably be more stable going forwards.

On Fri, Jan 22, 2016 at 5:04 AM, Martin J. O'Riordan via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160122/d9c8136e/attachment.html>

On Fri, Jan 22, 2016 at 10:57 AM, Reid Kleckner <rnk at google.com> wrote:
> It appears that the intended mechanism for extending the AsmStreamer is
> through the MCTargetStreamer interface:
> http://llvm.org/docs/doxygen/html/classllvm_1_1MCTargetStreamer.html
>
I think we are talking about two different things here. There is
MCAsmStreamer,
http://llvm.org/docs/doxygen/html/MCAsmStreamer_8cpp_source.html, line 41,
as well as MCTargetStreamer,
http://llvm.org/docs/doxygen/html/classllvm_1_1MCTargetStreamer.html. One
can't implement an interface (i.e overwrite a method) for MCAsmStreamer
since it is marked as final.

-- 
Rail Shafigulin
Software Engineer
Esencia Technologies
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160122/a82601b8/attachment.html>