563863 - nanojit: more fine-grained purity annotations for C functions

Status: RESOLVED WONTFIX

(Core Graveyard :: Nanojit, defect)

Description

[Nicholas Nethercote [inactive]]

Currently C functions called from LIR are marked as either pure or impure.  This affects how they can be optimized:

pure:
- can be DCE'd
- can be CSE'd

impure:
- cannot be DCE'd (ie. always live)
- cannot be CSE'd

But there's a middle ground.  A function that allocates some memory and possibly initializes it is not CSEable but might be DCEable.  Ie. similar to LIR_alloc.  (For it to actually be DCE'd requires any guard checking the result to be conditionally live, see bug 560994.)  

For this to be valid the store-AccSet should also be ACC_NONE.  (Note any initialisation done within the function to the newly allocated memory doesn't need to be represented in the store-AccSet, because when that initialisation occurs the memory cannot possibly be aliased.)

My main uncertainty here relates to the terminology.  Should I stick with "pure" and "impure" -- if so, what's the new category called? "pureAllocating"?  Or should I go with a more functional naming scheme, and have 'CSEable' and 'DCEable' bits?

Comment 1

[Edwin Smith]

I'd go with functional bits since I can't think of anything better, and its obvious what effect the bits would have.

TT needed a "fold" bit to suppress const folding for allocating functions, e.g:

   intToString(25)

Strings are immutable, so CSE was okay, but we did not want to inline a constant string pointer.  We dont need that fold bit anymore, but a non-cse function that allocates mutable memory is a similar situation.

Comment 2

[Nicholas Nethercote [inactive]]

Attachment: rough patch

Comment 3

[Nicholas Nethercote [inactive]]

Nanojit has been dead for several years. Its Bugzilla component has been moved to the graveyard (bug 984276).

I checked all the open bugs. They're all uninteresting, so I'm WONTFIXing them all. Apologies for the bugspam.