(For anyone following along, discussion has moved to email on review thread which phabricator isn't catching.)

In D99976#2703175, @echristo wrote:

I guess my question is "why? what does this make easier/harder/etc?"

A couple of pieces here.

1. We no longer have the chance of a nasty false negative bug. Before, we could fail to handle some intrinsics because they would not match IntrinsicInst.
2. As listed in the potential cleanups in the commit, we have multiple places in code which handled intrinsics generically, but then had to add extra casing for the invokable ones. We'll be able to clean that up.
3. For intrinsics which really are calls - which, admittedly, is many - this does complicate the pattern matching as you have to both match the intrinsicinst, and then cast to CallInst for interfaces which expect calls. (A quick survey shows many of those interfaces could reasonably take CallBase, but not all.) We could explore having two base classes - one for all intrinsics and one for call only intrinsics - not quite sure if the multiple inheritance works out there. It didn't seem worthwhile to justify exploration to me, if you disagree, let me know.

In D100884#2703064, @nikic wrote:

I don't think this is particularly valuable in terms of optimization power, but I do think the interface makes a bit more sense that way. Though I would suggest to go one step further and return std::pair<Value *, Value *>. That is, for a pair of input values, it returns a pair of output values that preserve the equality relationship. This should make the phi case particularly nice, because you can simply return {Start1, Start2} rather than checking for different possibilities of operand orders.

I played with this, but it turns out a bit more ugly than it sounds. It requires a bunch of duplicated boilerplate for the non-phi return points, and more importantly, greatly complicates the check to see that the recurrence is the LHS of the operation. I really didn't care for the resulting code structure.

Rebase over requested tests, and narrow initial scope to lshr only. Will return to ashr once this lands.

In D99687#2668491, @mkazantsev wrote:

I couldn't find tests for the following scenarios:

• Saturated ashr for positive & negative start;

test_ashr_tc_positive and test_ashr_tc_negative - not that 128 is INT_MIN for i8

LGTM withdrawn due to issue noticed by Nikita. Please address and refresh.

ping

I prototyped a couple of alternatives to this, and the resulting interface in matchSimpleRecurrence is ugly and error prone. Based on a survey of the existing users, SCEV is the only place which cares about the mismatch between LoopInfo and reachability.

Rebase over a couple added tests to cover cases which caused reviewer confusion. (For good cause.)

Rebase over requested test changes - thanks btw, good catch.

LGTM w/minor comments.

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

FYI, there was a nasty bug found in this patch. A fix is on review in https://reviews.llvm.org/D100779.

Proposed fix for the issue Nuno found here: https://reviews.llvm.org/D100779

In D100141#2697374, @nlopes wrote:

I've updated Alive2 with the new semantics and I see one regression:

Ok, wow. Thank you!

In D100676#2696511, @nhaehnle wrote:

I think the crux of the discussion is the second half of this sentence:

A nofree function is explicitly allowed to free memory which it (or a transitive callee) allocated or (if not nosync) arrange for another thread to free memory on its behalf.

I'm trying to figure out whether that second half makes sense by analogy with other attributes. For example, consider a function that is inaccessiblememonly. Is such a function allowed to use the inaccessible memory to communicate with another thread which then touches memory that is accessible to the caller? I'm pretty sure the assumption in existing LLVM code is that the answer is "no".

The honest truth is that our concurrency specification, and in particular, how it interacts with attributes is lacking to say the least.

In D100663#2697223, @fhahn wrote:

Thanks for taking a look and apologies for not doing a good job at conveying my thinking. My rational was that at the point we add the undef incoming value, it is yet undetermined which edge will be taken, so SCEV will constrain the undef value, but only to the incoming value of the scalar loop. In the final IR, both incoming values should result in the same value at runtime. Does that make sense or am I still missing something?

I see where you're going here (assuming the fix you mention after this in your long comment), and this could maybe be made to work, but I'm still nervous.

LGTM w/one suggested comment.

LGTM w/required changes.

In D100551#2697733, @mkazantsev wrote:

In D100551#2695408, @reames wrote:

I am really curious how you stumbled into this? There's only one currently enabled case which uses this codepath, and it has an explicit check for the GC abstract machine model which should cover your use case as I understand it?

I am planning to use this checker for loop load PRE. In case of concurrent GC, this check is too restrictive because nosync is never inferrable in practice.

Max, it might be worth talking offline about the specifics of your case.

Abandoning change. I still think this is valuable, but I think it's also clear I don't have the necessary background knowledge to drive this. If anyone else wants to pick this up, feel free.

LGTM

Looks close to ready for an LGTM if you're willing to split patch as suggested.

ping

Posted https://reviews.llvm.org/D100676 with an attempt to clarifying the nocapture case raised in my response to @nhaehnle above.

In D100141#2695406, @jdoerfert wrote:

LGTM, @nhaehnle should comment on the new wording probably.

JFYI, I don't intend to hold for @nhaehnle as the concern he raised appears orthogonal to the change being made in this review. I am happy to continue this discussion and post another patch if we thing further clarification is warranted for the concurrency case. I am leaning in that direction myself.

Change rejected. the nofree function attribute does explicitly allow freeing by another thread. See e.g. discussion here: https://reviews.llvm.org/D100141#2695360

(Not reviewing until issue raised on previous patch addressed, please request review when that one is resolved.)

Max, thank for you doing this. I think this is a really good idea.

@jdoerfert - Thanks for the wording suggestions; I took all of them.

In D100141#2691664, @nhaehnle wrote:

Thank you for doing this.

The interaction with multi-threading and capturing makes me mildly nervous. Perhaps I'm just confused, but the second paragraph of the definition there seems to imply that a nofree (but not-nosync) function f is allowed to free any memory that had a pointer to it captured somewhere. But this seems to contradict the first paragraph, which says that f "does not, directly or indirectly, call a memory-deallocation function (free, for example) on a memory allocation which existed before the call."

That certainly wasn't the intent. Which bit of wording gives that impression?

This is incorrect and will result in subtle miscompiles.

Adjust patch and description to be in line with the direction suggested by reviewer, and started in D100400.

Looks good to me as well.

Had not intended to reopen.

LGTM w/minor comments.

In D100339#2686649, @sstefan1 wrote:

I hope we are on the same page now.

Provided the RFC happens *before* any version of attributor is enabled by default, yes, we are.

LGTM w/one minor fix before submission.

Comments inline include one serious correctness issue.

Minor comments, this looks like it's evolved into a reasonable step forward. As things stand, I think this should go in with some minor stuff fixed, and we can iterate on details in further patches. This is already better than what we have now. :)

Sorry for not replying to your points inline, phab makes that difficult for long intermixed replies.

High level meta comment on enabling attributor by default, not on the code per se.

I really really like this idea, but the implementation, not so much. :)

Realized the alternative was strictly more in sync with existing code, so disregard this.