[llvm] r197740 - Change getStringRepresentation to skip defaults.

Alp Toker alp at nuanti.com
Sat Dec 21 11:44:38 PST 2013

On 21/12/2013 19:16, Sean Silva wrote:
> On Fri, Dec 20, 2013 at 11:15 AM, Rafael EspĂ­ndola 
> <rafael.espindola at gmail.com <mailto:rafael.espindola at gmail.com>> wrote:
>     * it is convenient to be able to produce IR from clang when a LLVM
>     backend is not linked in.
> Is that even possible? Doesn't clang inextricably depend on the 
> targets already? IIRC even libTooling needs to have targets built to 
> function (necessary for parsing [ms]inlineasm or something?).

It's entirely possible, and very useful.

This layering has been maintained consciously over the years and there's 
no need to require all backends to be build just to share a one-line 
DataLayout string.

clang's test suite works largely by checking emitted IR rather than 
machine code, so we get full test coverage despite not building in all, 
or indeed any LLVM machine targets. I rely on this every day for my 
work, and I think various distributors also turn off LLVM backends they 
don't use.

Realistically if a dependency creeps in, it's going to mean the more 
exotic targets get less testing, and moreover, users not building the 
x86 backend would be left with significantly reduced coverage because 
x86 is used as a convention to stabilise target triples.

As for the MS inline asm parser, it's a corner case and it's recently 
been fixed to degrade graciously rather than forcing all platforms to 
build an x86 target even if they don't need it.

I think we'll find a way to share the DataLayout strings in the 3.5 
cycle, but requiring every LLVM target machine to be built is not the 
way to go.


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

the browser experts

More information about the llvm-commits mailing list