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

[Fraser Cormack via llvm-dev]

Hi Craig,

I know I'm a bit late to the party, but I wanted to chime in and say 
that in my past two backends we've had to copy/paste MCAsmStreamer into 
our target just to override one or two methods.

For instance, in our current project we need to override:

EmitLabel() - We must escape certain characters
EmitBytes() - We must also escape and disallow certain characters, and 
fall back to emitting byte arrays
EmitLocalCommonSymbol() - We don't want the hard-coded "lcomm" symbol
EmitAssignment() - We don't use the hard-coded syntax

There will probably be more things we need to change further down the 
line, too.

I believe in the last project we had to override EmitLabel() because it 
used label prefix instead of a label suffix.

Some of these things might be fixable using the current architecture 
(like putting "lcomm" into MCAsmInfo) or by moving more into 
MCTargetStreamer and allowing that to do the entire job, instead of only 
part of it. For instance, I see MCAsmStreamer::EmitLabel calls 
MCStreamer::EmitLabel which calls MCTargetStreamer::EmitLabel, but then 
after all that happens, the MCAsmStreamer implementation still 
unconditionally does its own logic.

That, or it could just allow targets to inherit from it as they like. Is 
there a reason why it couldn't or shouldn't be done?

Thanks,
Fraser

On 22/01/16 00:04, Craig Topper via llvm-dev wrote:
> Isn't it also marked 'final' so it can't be inherited from anyway? What's
> your need to inherit from it?
>
> On Thu, Jan 21, 2016 at 2:42 PM, Rail Shafigulin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Does anybody know if there is a particular reason why MCAsmStreamer
>> doesn't have its own .h file?
>>
>>
>> https://github.com/llvm-mirror/llvm/blob/0e66a5f53c74056f95d178c86531d7d9cfb23da9/lib/MC/MCAsmStreamer.cpp#L41
>>
>> It seems like it is a good idea to have this class declared as its own
>> module ( its own .cpp and .h files). That would make it easier to inherit
>> from it if there is a need (like in my current case).
>>
>> Any help is appreciated.
>>
>> --
>> Rail Shafigulin
>> Software Engineer
>> Esencia Technologies
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>

-- 
Fraser Cormack
Staff Software Engineer, GPU Compilers
Codeplay Software Ltd
Level C, Argyle House
3 Lady Lawson Street,
Edinburgh EH3 9DR
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft

This email and any attachments may contain confidential and /or privileged information and  is for use  by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it,or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY