llvm dev - Feb 2012 - [LLVMdev] LinkModules triple/datatype mismatch warnings a bit strict?

Hi,

I'm fairly new at poking around in llvm internals so if you find
misconceptions / problems with the below let me know, this is just how I've
understood this so far.

When doing a build which uses functionality from LinkModules to combine bitcode
from different versions of LLVM, or between LLVM-GCC (I know) and Clang, 
I've noticed that multiple warnings which sometimes seem extraneous are
generated because a direct string comparison is used to determine whether to
warn.  The warnings are generated in llvm::ModuleLinker::run()

For example, it is possible to get a warning like:
WARNING: Linking two modules of different target triples: ... : 
armv5e-unknown-eabi and armv5e--unknown-eabi
That warning makes sense in theory because vendor / os are ambiguous in that
triple, but the warning itself seems unnecessary because both seem to internally
expand to "armv5e-unknown-unknown-eabi" in the current format.

Something similar happens with iOS targets because they contain a version in the
OS part of the string, so multiple warnings are generated about
"armv6-apple-ios4.0.0" and "armv6-apple-ios4.0.1" and
similar, which isn't really desirable most of the time.  Even whether the
arm version part of the string matters is kind of questionable given that
bitcode for armv6 shouldn't contain anything that would make it fail with
armv7, right?

This happens with the warning about module data layouts as well, where, (again
from the eabi example above) a warning can be displayed about two layouts which
are identical except for one explicitly listing stack function minimum stack
alignment (-S64) at the end of the string.  Stack alignment should be implied to
be 64 by eabi though, so the triple implies that part unless it is overridden
for some reason.    There's a very good chance I'm not understanding
something here, but this should only matter once everything is lowered to
machine code / assembly, no?

Thanks,
Gordon Keiser
Software Development Engineer
Arxan Technologies, Inc.
1305 Cumberland Ave, Ste 215
West Lafayette, IN
47906

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

On Feb 18, 2012, at 11:30 PM, Gordon Keiser wrote:
> Something similar happens with iOS targets because they contain a version
in the OS part of the string, so multiple warnings are generated about
“armv6-apple-ios4.0.0” and “armv6-apple-ios4.0.1” and similar, which isn’t
really desirable most of the time.  Even whether the arm version part of the
string matters is kind of questionable given that bitcode for armv6 shouldn’t
contain anything that would make it fail with armv7, right?
Yes, I agree.  This is overly annoying and not super useful.  It will be hard to
figure out how to subset this though.
> This happens with the warning about module data layouts as well, where,
(again from the eabi example above) a warning can be displayed about two layouts
which are identical except for one explicitly listing stack function minimum
stack alignment (-S64) at the end of the string.  Stack alignment should be
implied to be 64 by eabi though, so the triple implies that part unless it is
overridden for some reason.    There’s a very good chance I’m not understanding
something here, but this should only matter once everything is lowered to
machine code / assembly, no?
This actually is correct behavior.  TargetData is not a request by a frontend
for the target to do something: it is required to match what the target expects.
If a frontend isn't providing the right string, bad things will happen. 
That said, we do want old .bc files to work with new versions of LLVM, so
perhaps we should tolerate *missing* pieces like this better.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120220/6c5794a8/attachment.html>