llvm dev - Mar 2015 - [LLVMdev] DataLayout: Module vs Target

Hi all,

The Language Reference says:

"The function of the data layout string may not be what you expect.
Notably, this is not a specification from the frontend of what alignment the
code generator should use.
Instead, if specified, the target data layout is required to match what the
ultimate code generator expects. This string is used by the mid-level optimizers
to improve code, and this only works if it matches what the ultimate code
generator uses. If you would like to generate IR that does not embed this
target-specific detail into the IR, then you don’t have to specify the string.
This will disable some optimizations that require precise layout information,
but this also prevents those optimizations from introducing target specificity
into the IR.”
I understand from this that the DataLayout present in the Module *must* match
the DataLayout that the Target will use.
There is no runtime check to enforce this at that time. 
My impression is that I can set the DataLayout on the Module to be big-endian
and run the optimizer and the X86 backend.
The IR-level passes will use the DataLayout supplied with the Module and the
backend code will silently use the TargetMachine one.
Should we enforce that the DataLayout attached to the Module matches the one
expected by the Target?
Thanks,
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150310/9de5dfa4/attachment.html>

> On Mar 10, 2015, at 5:19 PM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> 
> Hi all,
> 
> The Language Reference says:
> 
> "The function of the data layout string may not be what you expect.
Notably, this is not a specification from the frontend of what alignment the
code generator should use.
> Instead, if specified, the target data layout is required to match what the
ultimate code generator expects. This string is used by the mid-level optimizers
to improve code, and this only works if it matches what the ultimate code
generator uses. If you would like to generate IR that does not embed this
target-specific detail into the IR, then you don’t have to specify the string.
This will disable some optimizations that require precise layout information,
but this also prevents those optimizations from introducing target specificity
into the IR.”
> I understand from this that the DataLayout present in the Module *must*
match the DataLayout that the Target will use.
> There is no runtime check to enforce this at that time. 
> My impression is that I can set the DataLayout on the Module to be
big-endian and run the optimizer and the X86 backend.
> The IR-level passes will use the DataLayout supplied with the Module and
the backend code will silently use the TargetMachine one.
> Should we enforce that the DataLayout attached to the Module matches the
one expected by the Target?
Yes.  :-)

—Owen

On Tue, Mar 10, 2015, 5:19 PM Mehdi Amini <mehdi.amini at apple.com>
wrote:

Hi all,

The Language Reference says:

"The function of the data layout string may not be what you expect.
Notably, this is not a specification from the frontend of what alignment
the code generator should use.

Instead, if specified, the target data layout is required to match what the
ultimate *code generator* expects. This string is used by the mid-level
optimizers to improve code, and this only works if it matches what the
ultimate code generator uses. If you would like to generate IR that does
not embed this target-specific detail into the IR, then you don’t have to
specify the string. This will disable some optimizations that require
precise layout information, but this also prevents those optimizations from
introducing target specificity into the IR.”

I understand from this that the DataLayout present in the Module *must*
match the DataLayout that the Target will use.

There is no runtime check to enforce this at that time.

My impression is that I can set the DataLayout on the Module to be
big-endian and run the optimizer and the X86 backend.

The IR-level passes will use the DataLayout supplied with the Module and
the backend code will silently use the TargetMachine one.

Should we enforce that the DataLayout attached to the Module matches the
one expected by the Target?

 Definitely. That said clang does this in asserts mode.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150311/53a9cd61/attachment.html>

> On Mar 10, 2015, at 8:50 PM, Eric Christopher <echristo at gmail.com>
wrote:
> 
> 
> 
> On Tue, Mar 10, 2015, 5:19 PM Mehdi Amini <mehdi.amini at apple.com
<mailto:mehdi.amini at apple.com>> wrote:
> 
> Hi all,
> 
> The Language Reference says:
> 
> "The function of the data layout string may not be what you expect.
Notably, this is not a specification from the frontend of what alignment the
code generator should use.
> 
> Instead, if specified, the target data layout is required to match what the
ultimate code generator expects. This string is used by the mid-level optimizers
to improve code, and this only works if it matches what the ultimate code
generator uses. If you would like to generate IR that does not embed this
target-specific detail into the IR, then you don’t have to specify the string.
This will disable some optimizations that require precise layout information,
but this also prevents those optimizations from introducing target specificity
into the IR.”
> 
> I understand from this that the DataLayout present in the Module *must*
match the DataLayout that the Target will use.
> 
> There is no runtime check to enforce this at that time. 
> 
> My impression is that I can set the DataLayout on the Module to be
big-endian and run the optimizer and the X86 backend.
> 
> The IR-level passes will use the DataLayout supplied with the Module and
the backend code will silently use the TargetMachine one.
> 
> Should we enforce that the DataLayout attached to the Module matches the
one expected by the Target?
> 
> 
> Definitely. That said clang does this in asserts mode.
> 
Can you be more specific?
From what I see, clang (for an IR file only of course) will match the triple,
but not the DataLayout (or I haven’t found where):

    if (TheModule->getTargetTriple() != TargetOpts.Triple) {
      CI.getDiagnostics().Report(SourceLocation(),
                                 diag::warn_fe_override_module)
          << TargetOpts.Triple;
      TheModule->setTargetTriple(TargetOpts.Triple);
    }


Mehdi

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