[llvm-commits] [llvm] r74478 - in /llvm/trunk: include/llvm/MC/MCStreamer.h lib/MC/MCAsmStreamer.cpp test/MC/AsmParser/directive_align.s tools/llvm-mc/AsmParser.cpp tools/llvm-mc/AsmParser.h

[Daniel Dunbar]

On Tue, Jun 30, 2009 at 11:40 PM, Chris Lattner<clattner at apple.com> wrote:
> On Jun 29, 2009, at 4:47 PM, Daniel Dunbar wrote:
>> URL: http://llvm.org/viewvc/llvm-project?rev=74478&view=rev
>> Log:
>> llvm-mc: Parse .{,b,p2}align{,w,l} directives.
>
>> +++ llvm/trunk/include/llvm/MC/MCStreamer.h Mon Jun 29 18:46:59 2009
>> @@ -135,7 +135,7 @@
>>     /// This used to implement the .align assembler directive.
>>     ///
>>     /// @param ByteAlignment - The alignment to reach. This must be
>> a power of
>> -    /// two.
>> +    /// two on some targets.

I don't really understand your comments, but I'll try to answer:

> What is the right answer here for .align?  Though slightly incovenient
> for the asm/printer, I think it makes sense to make the interface to
> be target-independent.

Yes, I agree. I believe the defined interface is strong enough to
support all Darwin and gas alignment directives; although it is the
responsibility of the client to not use the interface to emit
something the target cannot support (non-power-of-two alignment on
Darwin, for example). My understand was we agreed on this approach...
:)

In the future I think the interface should have a facility for
reporting errors when an "out-of-range" call is made, but for the time
being I don't think its worth worrying about.

The assembler front-end is responsible for lowering the target
alignment directive to this interface appropriately. For example, on
Darwin:
--
.p2alignl 3, foo
--
should lower to the equivalent of
--
.p2align 2, 0
.p2alignl 3, foo
--
in order to respect the Darwin semantics for filling the alignment
bytes prior to reaching the alignment of the foo-expr (4-bytes, in
this case).

For gas, the same construct lowers to something like:
--
.p2align 1, foo & 0xFF
.p2alignw 2, (foo >> 8) & 0xFFFF
.p2alignl 3, foo
--
([in]validity of this expansion left to the reader).

Yes, this is pretty gross, but when possible I would prefer to push
complexity towards the front-end. The other obvious alternative is to
provide multiple MCStreamer APIs which match the semantics we want to
support (including a generic superset, when possible), and expect the
front-end to use the right interface when coming from a .s file, and
other clients to use the generic version when possible, or their own
target knowledge to do the right thing. I expect that we will end up
taking both approaches depending on the feature...

> For example, the alignment could always be
> specified in log2 form.  If the TargetAsmInfo says that .align is not
> in log2 form, the parser/printer would be responsible for changing
> it.  This approach is convenient for the code generator.  What do you
> think?

Did I answer this?

 - Daniel

> -Chris
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>