Page MenuHomePhabricator

[rs4gc] Strip memory related attributes consistently
Needs ReviewPublic

Authored by reames on Fri, Apr 2, 9:59 AM.



I noticed that rs4gc is not stripping a number of memory aliasing related attributes. We do strip some from call sites, but don't strip the same ones from declarations or parameters.

Why do we need to strip these? Two answers:

  1. Safepoints conceptually read and write to the entire garbage collected heap in the physical model. We need this to preserve ordering of all loads and stores with respect to possible relocation.
  2. We can infer other attributes from these. For instance, readnone can imply both nofree and nosync. Both of which don't hold after physical rewriting.

I'm mostly posting for review to give a chance for a sanity check, and a perf test if interested. I could see this negatively impacting optimization after lowering. I doubt it's a large effect, but that might be worth measuring.

Diff Detail

Event Timeline

reames created this revision.Fri, Apr 2, 9:59 AM
reames requested review of this revision.Fri, Apr 2, 9:59 AM
Herald added a project: Restricted Project. · View Herald TranscriptFri, Apr 2, 9:59 AM

Hi Philip, it seems this change causes functional failure.


It seems that leads to functional issue.
The problem here is that this function is invoked for any declared function in a module including llvm intrinsics which are not covered by statepoint instruction.

In my failed test it appeared llvm.x86.sse2.cvttsd2si64 and as a result readnone attribute has been cleared from it.

Later it could not find this intrinsic while linking:
Cannot select: intrinsic %llvm.x86.sse2.cvttsd2si64

I landed a change (01801d5274) which should address the reported issue. (It was essentially a latent bug in the existing code.)

Once that bakes for a bit, I'd appreciate a retest cycle to see if anything else falls out. That one definitely wasn't anything I was expecting.