This is an archive of the discontinued LLVM Phabricator instance.

Support -fforce-tbaa command-line option
AbandonedPublic

Authored by kosarev on Aug 17 2017, 8:10 AM.

Details

Summary

This patch refines the code that determines when TBAA information shall be generated and introduces clang option -fforce-tbaa and cc1 option -force-tbaa to force use of TBAA regardless of other options, such as -O ones. The patch also adds tests for these new options.

Diff Detail

Event Timeline

kosarev created this revision.Aug 17 2017, 8:10 AM
kosarev edited the summary of this revision. (Show Details)
rjmccall edited edge metadata.Aug 17 2017, 12:03 PM

(1) Why do you want this?
(2) Why does this need to be a driver option? Why would an end-user care about internal details like whether TBAA metadata are emitted in IR?
(3) Why are the driver and -cc1 options spelled differently?

Hello John. Thanks for reviewing.

The motivation behind this patch is that currently there is no way to leverage TBAA in LTO-enabled builds and/or builds with custom IR processing with IR objects produced with -O0. Also, having a way to generate unoptimized IR modules with TBAA information therein would help with writing TBAA tests and make them faster. From this point of view the new options are no different than -disable-O0-optnone and -fno-inline.

As to spelling, the new options seem to follow the existing conventions, just like -fno-struct-path-tbaa turns into -no-struct-path-tbaa. How do you expect them to be spelled?

And as a general note, TBAA information is an essential part of the resulting IR module and affects how far we can go with optimizations, which is what I would expect users do care about.

Hello John. Thanks for reviewing.

The motivation behind this patch is that currently there is no way to leverage TBAA in LTO-enabled builds and/or builds with custom IR processing with IR objects produced with -O0.

We don't care about doing LTO on object files built with -O0. -O0 is explicitly meant to prevent further optimization of that code; IIRC Chandler did some work recently to explicitly reinforce that.

I suspect that "builds with custom IR processing" are your actual motivation here. Can you expand on that?

Also, having a way to generate unoptimized IR modules with TBAA information therein would help with writing TBAA tests and make them faster. From this point of view the new options are no different than -disable-O0-optnone and -fno-inline.

The right way to write TBAA tests is to pass -O -disable-llvm-optzns, not to come with new flags to enable generating every specific optimization feature in unoptimized builds.

As to spelling, the new options seem to follow the existing conventions, just like -fno-struct-path-tbaa turns into -no-struct-path-tbaa. How do you expect them to be spelled?

That's a recent addition that I must have missed when it went in. Frontend flags do not generally arbitrarily differ from driver flags.

And as a general note, TBAA information is an essential part of the resulting IR module and affects how far we can go with optimizations, which is what I would expect users do care about.

Users care about optimizations in optimized builds.

John.

kosarev abandoned this revision.Dec 4 2018, 12:54 AM