llvm dev - Apr 2015 - [LLVMdev] RFC: Machine Level IR text-based serialization format

On 2015-04-28 19:14, Quentin Colombet wrote:
> Personally I would rather not have to write YAML inputs but instead
> resort on the what the machine dumps look like. That being said, I can
> live with YAML :).
> 
YAML is what is suggested in the FIXME for the textual Machine IR, so
that might be the motivation behind Alex's choice.

I sort of agree that it could be better to go with a "proprietary"
format based off of the dumps. This means that a dedicated Machine
IR parser could be implemented for the purposes of library users who
want to open the files. I also think that the dumps are much easier
to diff and read.

There are parts of the suggested YAML format that seem to require some
parsing anyway, like the instruction strings. If YAML is going to be 
used,
I think it would be better to let the instructions be encoded in YAML
instead of leaving them as a string, if that makes sense.

/ Bevin

2015-04-28 11:09 GMT-07:00 Bevin Hansson <bevinh at sics.se>:
> On 2015-04-28 19:14, Quentin Colombet wrote:
>
>> Personally I would rather not have to write YAML inputs but instead
>> resort on the what the machine dumps look like. That being said, I can
>> live with YAML :).
>>
>>
> YAML is what is suggested in the FIXME for the textual Machine IR, so
> that might be the motivation behind Alex's choice.
>
> I sort of agree that it could be better to go with a
"proprietary"
> format based off of the dumps. This means that a dedicated Machine
> IR parser could be implemented for the purposes of library users who
> want to open the files. I also think that the dumps are much easier
> to diff and read.
>
> There are parts of the suggested YAML format that seem to require some
> parsing anyway, like the instruction strings. If YAML is going to be used,
> I think it would be better to let the instructions be encoded in YAML
> instead of leaving them as a string, if that makes sense.
>
> / Bevin

Initially I was thinking about developing a text-based format that's not
based on YAML, but is closer in spirit to the LLVM IR. However, I found
that a structured format like YAML lends itself quite well to the machine
level IR. At the same time the instructions themselves don't work that well
with YAML, thus I decided on this hybrid approach. Therefore I don't
think that instructions should be in YAML, as they would just get too
verbose.

I understand that a non YAML format has its own advantages and may be
preferred by the majority. If the community decides that another format is
better,
I would be happy to work on that.

Alex.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150428/a833ede2/attachment.html>

On Tue, Apr 28, 2015 at 11:54 AM, Alex L <arphaman at gmail.com> wrote:
> Initially I was thinking about developing a text-based format that's
not
> based on YAML, but is closer in spirit to the LLVM IR. However, I found
> that a structured format like YAML lends itself quite well to the machine
> level IR. At the same time the instructions themselves don't work that
> well
> with YAML, thus I decided on this hybrid approach. Therefore I don't
> think that instructions should be in YAML, as they would just get too
> verbose.
>
> I understand that a non YAML format has its own advantages and may be
> preferred by the majority. If the community decides that another format is
> better,
> I would be happy to work on that.
>
I think the YAML hybrid makes a sort of sense.

The instructions need to be dense in order to keep the format readable.

Machine functions and basicblocks have loads of side table data
(MachineModuleInfo, MachineFunctionInfo, the target-specific info, etc)
that needs to be serialized in order to write interesting tests. Therefore,
it's better use an easily extensible format for them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150428/cae01776/attachment.html>