Skip to content

Conversation

@davidtrevelyan
Copy link

No description provided.

Copy link
Collaborator

@cjappl cjappl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this is good, a few small nits but this is very similar to how I would have it.

return PA;
}

static void transformRealtimeUnsafeFunction(Function &F) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit (take it or leave it):

Transform is a little vague, could be more descriptive as to the actual transformation taking place

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, agreed

static PreservedAnalyses rtsanPreservedAnalyses() {
PreservedAnalyses PA;
PA.preserveSet<CFGAnalyses>();
return PA;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would get rid of this function and leave these explicit. I think the loop changing we will do will not preserve CFG, so I think it is OK to just do this explicitly in our main block

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm yeah - part of my refactoring in the main pass function was intended to have a sequence of:

if (condition) {
    return transformXYZ(...);
}
else if (condition) {
    return transformABC(...);
}

... to express the intent that these transformations are mutually exclusive and return early. But now I'm thinking about it, it doesn't really need to be that way - and it's a bit early days to start those sorts of refactors. So yeah, I think I'll revert this as you suggest

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On second thoughts, we still need it in two places. I've updated the function name to be more explicit, though - you'll see this in my latest PR. When we no longer need it as part of the sanitize_realtime pass, we can inline it then. I think it's better to keep it in this case, don't you?


FunctionType *FuncType =
FunctionType::get(Type::getVoidTy(F.getContext()),
{PointerType::getUnqual(F.getContext())}, false);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should call reviewer eyes to this code when we post this so we make sure it is correct (not saying it isn't just that I have no clue about this code)


; RealtimeSanitizer pass should insert __rtsan_expect_not_realtime at function entrypoint
; CHECK-LABEL: @blocking_function()
; CHECK-NEXT: call{{.*}}@__rtsan_expect_not_realtime({{ptr .*}})
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice one!

@davidtrevelyan davidtrevelyan deleted the rtsan/blocking-2-llvm-pass branch August 30, 2024 15:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants