As best I can tell, all this code _actually_ cares about is that it's a
function from an allocator family, not that it's specifically realloc or
free (which are the only options anyway). We can check for the allocator
family instead of looking at "is realloc like" and "is free like"
separately. The downside is that we need to add the free() codepath to
the work list, but since it returns nothing that should be
inconsequential in terms of cost.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Unit Tests
Time | Test | |
---|---|---|
60,040 ms | x64 debian > MLIR.Examples/standalone::test.toy | |
60,030 ms | x64 debian > libFuzzer.libFuzzer::large.test |
Event Timeline
Comment Actions
I don't think this change is semantically right. For example, the function could now also be an allocator function that just happens to accept a pointer argument -- say, an allocator that allocates into a memory region. I think we do need to explicitly check that it's a free/realloc.
What's the motivation for this change?
Comment Actions
Oh, great point. This was an unconsidered leftover from a previous incarnation of this (before allockind() existed) and it can be replaced by D124425 (which comes later in the sequence). I'll mark this as abandoned. Thanks!