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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160121/70e08a85/attachment.html>

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
>
>

-- 
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160121/2348447a/attachment.html>

On Thu, Jan 21, 2016 at 4:04 PM, Craig Topper <craig.topper at gmail.com>
wrote:
> Isn't it also marked 'final' so it can't be inherited from
anyway? What's
> your need to inherit from it?
> --
> ~Craig
>
Oops, missed the final part. I need to change the alignment. For my target
it is sort of independent of the data layout. I was going to overwrite
void MCAsmStreamer::EmitValueToAlignment(unsigned ByteAlignment, int64_t
Value, unsigned ValueSize, unsigned MaxBytesToEmit).

What is the reason it was made final? Why not to separate this class into
its own module?
-- 
Rail Shafigulin
Software Engineer
Esencia Technologies
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160121/fd0c6ef9/attachment.html>

> On Jan 21, 2016, at 14:42, 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
<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

I have patches to move parts of it to a header:

http://reviews.llvm.org/D11822 <http://reviews.llvm.org/D11822>
http://reviews.llvm.org/D11823 <http://reviews.llvm.org/D11823>


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160121/87a9af04/attachment.html>

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