[llvm-dev] Why is there no EmitInt64 in AsmPrinter?

[James Henderson via llvm-dev]

I took a look at the code a bit more, and it looks like there are no users
of EmitIntValue with an explicit 8-byte size, although plenty use some
other mechanism to specify the size, which could clearly be 8 bytes (e.g.
when emitting DW_FORM_data8 data, or address sizes). As far as I can tell,
there is no DWARF64 writing support anywhere in LLVM, so the obvious
use-case for writing a literal 64-bit value is not there either. Type
signatures, along with other DWARF DIEs are written with an
indirectly-specified size. I think the fact that this can be a value of 8
probably means that this is safe, but I'm uncertain.

On 20 March 2018 at 18:49, <paul.robinson at sony.com> wrote:

> DWARF already needs to emit 64-bit values, being the type-unit hashes.
> How is that being done?  (If it's going directly to the streamer, then
> we're already assuming all assemblers are okay with what the streamer does,
> and adding an AsmPrinter helper seems very reasonable.)
>
> --paulr
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *James
> Henderson via llvm-dev
> *Sent:* Friday, March 09, 2018 7:44 AM
> *To:* llvm-dev
> *Subject:* [llvm-dev] Why is there no EmitInt64 in AsmPrinter?
>
>
>
> Hi all,
>
> The AsmPrinter class supports functions like EmitInt8, EmitInt16, and
> EmitInt32 for writing a 1/2/4 byte directive to the assembly. Each of these
> calls the MCStreamer::EmitIntValue method with the corresponding size. For
> some reason, there is no EmitInt64, and I was wondering if there was a
> fundamental reason why? The EmitIntValue function appears to support 8-byte
> inputs.
>
> I dug into this a bit more and found a commit way back in 2010 (r100296)
> that removed the "EmitInt64" equivalent, with no explanation (presumably it
> was unused).
>
> I'd find this function quite helpful - I'm currently working on extending
> the DwarfGenerator unit-test helper class to support debug line, and I'd
> like to be able to write 8 byte values (e.g. to reflect DWARF64 lengths). I
> could trivially reinstate the function, but if there's a good reason not
> to, it would be good to know before I go to the effort of creating a review
> for it.
>
> Thanks for any help.
>
> James
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180321/ed36b6ec/attachment.html>