Depnds on D20116
Details
Diff Detail
Event Timeline
I am planning to add the speculatable attribute to all the intrinsics listed in this function in a separate patch.
Do we want to also change this function to give information about speculatable cost as proposed in this review: https://reviews.llvm.org/D20116
Another question I have is should the presence of speculatable by itself be enough for isSafeToSpeculativelyExecute() to return true. This would mean that the callers would be responsible for checking memory dependencies before speculating. The alternative would be to make isSafeToSpeculativelyExecute() require both the readnone and speculatable attributes.
Doesn't the SpeculativeExecution already considered the TTI cost for this anyway?
lib/Analysis/ValueTracking.cpp | ||
---|---|---|
3120–3125 | Is invoke allowed to be speculatable? |
SimplifyCFG does, so we seem to be okay there.
This LGTM.
lib/Analysis/ValueTracking.cpp | ||
---|---|---|
3120–3125 | No. The invoked function might throw. If it can't throw, then we'll convert it into a regular call during simplification. |
lib/Analysis/ValueTracking.cpp | ||
---|---|---|
3120–3125 | So do I need to check for invoke here, or is it safe to assume that functions referenced by invoke will never have the speculatable attribute.? |
lib/Analysis/ValueTracking.cpp | ||
---|---|---|
3120–3125 | No, I don't think so. |
lib/Analysis/ValueTracking.cpp | ||
---|---|---|
3120–3125 | A verifier check should probably be added in the other patch for this if it isn't already there |
lib/Analysis/ValueTracking.cpp | ||
---|---|---|
3120–3125 | Do you mean a verifier check that a function that might throw is marked as speculatable? I'm not sure that's a good idea. |
lib/Analysis/ValueTracking.cpp | ||
---|---|---|
3120–3125 | I mean the opposite, that an invoke never has a speculatable |
lib/Analysis/ValueTracking.cpp | ||
---|---|---|
3120–3125 | IMO, it seems like it would belong more in llvm's Lint analysis than a verifier check. |
lib/Analysis/ValueTracking.cpp | ||
---|---|---|
3120–3125 | I agree. We could easily end up with invoked functions being speculatable as an intermediate state (especially if we start inferring the attribute). Also, it is not clearly a logical contradiction. The user might add the speculatable attribute on a function that might throw because the user does not care if the exception is thrown early. I'm not sure what we would do with that, however, because moving the catch blocks around to speculate the invoke seems unlikely worthwhile. |
I'd do auto * here.