[llvm-commits] Improvements to PassManager

Chandler Carruth chandlerc at google.com
Tue Nov 20 03:05:12 PST 2012

On Mon, Nov 19, 2012 at 4:46 AM, Kostya Serebryany <kcc at google.com> wrote:
> On Mon, Nov 19, 2012 at 4:33 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
>> FYI, it shouldn't be moved back to a module pass. I'm just suggesting the
>> logic in doFinalization should be lifted into a module pass.
> You mean split the AddressSanitizer class into two? This will cause some
> pain.
> There are things computed at doInitialization or at runOnFunction, and then
> used in doFinalization.
> E.g. DynamicallyInitializedGlobals will need to be computed twice.
> GlobalsCreatedByAsan will have to be replaced with some other way to mark
> globals created by asan (use metadata nodes? match name strings?)

This is what I meant... I realize it's not trivial, but I think it's
the correct thing to do.

Essentially, transforms on globals themselves should be done as a
module pass (much like globalopt is today a module pass), and
transforms on the functions as a function pass.The global transforms
are also much simpler / more constrained, and so it seems less likely
for them to benefit from being a function pass.

To address your specific points:

DynamicallyInitializedGlobals appears to only be created inside the
finalization step, even though it is referenced from outside of it...
I've no idea how the outside references can work currently. That said,
computing this twice (once in the initialization step of the function
pass, once in the module pass) doesn't seem terribly costly.

GlobalsCreatedByAsan should indeed be handled in some other way. I'm
hopeful that the new attribute system will be generalized to support
globals as well as functions, which would allow us to just not mark
the ASan globals as instrumented. I'd also be fine using a particular
naming convention, there are already some naming convention stuff done
in ASan, so it wouldn't be too weird.

Are there any other bits that would be made particularly awkward by this split?

Is this something you folks have bandwidth for? I can look at it if not.

More information about the llvm-commits mailing list