This is an archive of the discontinued LLVM Phabricator instance.

[WIP][NewPM] Port msan
AbandonedPublic

Authored by philip.pfaffe on Nov 11 2018, 10:27 AM.

Details

Summary

msan as most sanitizers creates a new function to initialize itself,
which function passes cannot do. To keep it as a function pass, I moved the
pass's intialization around:

  • Make a free function for creating the global constructor function
  • The opt tool calls this function when passing a command line option
  • The remaining initialization only creates function declarations and metadata. This I now do lazily when visiting the first function. Consequently I need to keep state in the Pass, which is unfortunate. If this survives review, we need to be careful with other sanitizers when doing this, because state is kept per PM instance, _not_ per module. So this is just best-effort.

Diff Detail

Event Timeline

philip.pfaffe created this revision.Nov 11 2018, 10:27 AM
philip.pfaffe retitled this revision from [NewPM] Port msan to [WIP][NewPM] Port msan.Nov 13 2018, 11:08 AM
  • Make a free function for creating the global constructor function
  • The opt tool calls this function when passing a command line option

What is the benefit of having free function compared to having a module-level pass that does the same?

Consequently I need to keep state in the Pass, which is unfortunate.

This is really unfortunate. What about introducing (a module level) analysis?
It will have to be force-run on module level, but then we will be able to rely on AnalysisManager in terms of per-Module-per-Pipeline memory management.

glider added a subscriber: glider.Dec 5 2018, 6:25 AM

I think I'm missing some context here.
What is the problem you are trying to solve?

msan as most sanitizers creates a new function to initialize itself, which function passes cannot do.

Technically they can, at least now. Are there any upcoming changes to that?

  • Make a free function for creating the global constructor function
  • The opt tool calls this function when passing a command line option

What is the benefit of having free function compared to having a module-level pass that does the same?

Having a pass introduces dependencies between passes, which I find unsetteling. I.e. when you use the asan pass, you _must_ also use the asan-init pass, or otherwise you end up with IR that you can't compile without linker errors. That being said, the same is of course true when using the command line argument approach, so asan-init might not be the worst at the end of the day.

This is really unfortunate. What about introducing (a module level) analysis?
It will have to be force-run on module level, but then we will be able to rely on AnalysisManager in terms of per-Module-per-Pipeline memory management.

The same argument I raised on D54337: You loose all the locality function pass pipelines give you.

I think I'm missing some context here.
What is the problem you are trying to solve?

msan as most sanitizers creates a new function to initialize itself, which function passes cannot do.

Technically they can, at least now. Are there any upcoming changes to that?

They aren't allowed to in the new pass manager.

philip.pfaffe abandoned this revision.Jan 3 2019, 6:03 AM

Superseded by D55647.