I like my LLVM IR text to have nice value names, e.g.
%add = add ...
%mul = mul ...
And this all works well if the build has asserts enabled. If the build
does not have asserts enabled, it's not so nice:
%1 = add ...
%2 = mul ...
I understand the use for obfuscating names, but the choice to make this
dependent on whether or not asserts are enabled seems odd to me. At the
very least it's surprising. It took some time for me to figure out why
some of our builds behaved differently than others.
Is this an intentional design choice? If so, what's the rationale? If
not, would it make sense to add a CMake option to specify whether
textual IR preserves names or not rather than overloading
ENABLE_ASSERTIONS?
-David
On Wed, Jan 9, 2019 at 2:12 PM David Greene via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > I like my LLVM IR text to have nice value names, e.g. > > %add = add ... > %mul = mul ... > > And this all works well if the build has asserts enabled. If the build > does not have asserts enabled, it's not so nice: > > %1 = add ... > %2 = mul ... > > I understand the use for obfuscating names, but the choice to make this > dependent on whether or not asserts are enabled seems odd to me. At the > very least it's surprising. It took some time for me to figure out why > some of our builds behaved differently than others. > > Is this an intentional design choice? If so, what's the rationale? If > not, would it make sense to add a CMake option to specify whether > textual IR preserves names or not rather than overloading > ENABLE_ASSERTIONS? >You can use `opt -instnamer`. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare
And the clang behavior can be controlled with -fdiscard-value-names/-fno-discard-value-names ~Craig On Wed, Jan 9, 2019 at 2:16 PM Davide Italiano via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Wed, Jan 9, 2019 at 2:12 PM David Greene via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > I like my LLVM IR text to have nice value names, e.g. > > > > %add = add ... > > %mul = mul ... > > > > And this all works well if the build has asserts enabled. If the build > > does not have asserts enabled, it's not so nice: > > > > %1 = add ... > > %2 = mul ... > > > > I understand the use for obfuscating names, but the choice to make this > > dependent on whether or not asserts are enabled seems odd to me. At the > > very least it's surprising. It took some time for me to figure out why > > some of our builds behaved differently than others. > > > > Is this an intentional design choice? If so, what's the rationale? If > > not, would it make sense to add a CMake option to specify whether > > textual IR preserves names or not rather than overloading > > ENABLE_ASSERTIONS? > > > > You can use `opt -instnamer`. > > -- > Davide > > "There are no solved problems; there are only problems that are more > or less solved" -- Henri Poincare > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190109/d24931f0/attachment.html>
Davide Italiano <davide at freebsd.org> writes:>> Is this an intentional design choice? If so, what's the rationale? If >> not, would it make sense to add a CMake option to specify whether >> textual IR preserves names or not rather than overloading >> ENABLE_ASSERTIONS? > > You can use `opt -instnamer`.Ok, but that's somewhat cumbersome with clang and it still doesn't really answer why things are set up they way they are. Why should building with asserts change the observable behavior of a (correct) compiler? That's surprising and not in a good way. -David