[llvm] r197740 - Change getStringRepresentation to skip defaults.

[Rafael Espíndola]

> What is the reason that we don't just have a single point of truth for this?
> Phrased another way: why is it necessary to maintain these DataLayout
> strings independently, once in clang and once in LLVM core?

There is some historical issues I am sure, but the main conflicting
use cases that exist today are

* tools like llc need the DataLayout, so this has to live in llvm somewhere.
* targets are fairly plugable in llvm, so each target ends up having
code to produce its DataLayout.
* it is convenient to be able to produce IR from clang when a LLVM
backend is not linked in.

I initially wrote a patch that would always use the LLVM provide
strings by dropping the last use case. Alp convinced me that it was
useful to keep it, so for now we have settled on at least asserting
that the strings match when the llvm target is available (patches
under code review on the list).

We chatted a bit on IRC and it might be possible to refactor things to
avoid the duplication in a followup step. One of the ideas being for
the in tree targets to put their DataLayout somewhere in
llvm/lib/CodeGen so that clang can access it even when the target
itself is not linked in.

Cheers,
Rafael