[llvm-dev] Is there a reason why MCAsmStreamer class doesn't have its own .h file?

[Reid Kleckner via llvm-dev]

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>