On 2025-04-09 08:30, Qing Zhao wrote:
After expand phase, .ACCESS_WITH_SIZE will be replaced by its first argument.
And all the size expression before the call to .ACCESS_WITH_SIZE might be dead
code eliminated later in the RTL phases.
So, I don’t think there will be run-time overhead concern.
However, the IR size increase in the TREE optimization phase might impact the
Optimization heuristics that base on IR size, for example, inlining decision,
etc.
That’s the major concern for me.
I mean that the IR size estimation should also account for the fact that
the runtime overhead of .ACCESS_WITH_SIZE is zero.
A good measure of this could be to get a sense of additional coverage one could
get for __bdos with this change vs without it for, e.g. the kernel. You could
maybe use fortify-metrics[1] to find that.
Why there will be additional coverage with this change? (This change means to
replace pointer reference with structure type with FAM by a call to
.ACCESS_WITH_SIZE
in C FE)
Based on my current patch (expand the counted_by refs to size expressions by
demand for __bdos),
All the __bdos should be covered, right?
Yes, I mean if you're concerned that there's a performance tradeoff due
to this change, you could quantify the coverage improvement to make the
case that there's a measurable improvement in security in the generated
code, which justifies the performance overhead.
Something like: "The total coverage for __bdos improved by X% for the
kernel build, which justifies the additional overhead of up to N
instructions for the size expression caused by this patch".
Thanks,
Sid
