> Am 13.11.2023 um 15:52 schrieb Alexander Monakov <amona...@ispras.ru>:
>
>
>> On Mon, 13 Nov 2023, Richard Biener wrote:
>>
>> Another generic comment - placing a built-in call probably pessimizes code
>> generation unless we handle it specially during alias analysis (or in
>> builtin_fnspec).
>
> But considering the resulting code is intended to be run under Valgrind,
> isn't a bit worse quality acceptable? Note that we don't want loads
> following the built-in to be optimized out, they are necessary as they
> will be flagged by Valgrind as attempts to read uninitialized memory.
>
> I suspect positioning the pass immediately after build_ssa as we do now
> is quite imperfect because we will then instrument 'x' in
>
> void f()
> {
> int x, *p;
> p = &x;
> }
>
> Ideally we'd position it such that more locals are put in SSA form,
> but not too late to miss some UB, right? Perhaps after first pass_ccp?
I guess it’s worth experimenting. Even doing it right before RTL expansion
might work. Note if you pick ccp you have to use a separate place for -O0
>> I also don't like having another pass for this - did you
>> investigate to do the instrumentation at the point the CLOBBERs are
>> introduced?
>
> I don't see a better approach, some CLOBBERs are emitted by the C++
> front-end via build_clobber_this, some by omp-expand, some during
> gimplification. I'm not a fan of useless IR rescans either, but
> this pass is supposed to run very rarely, not by default.
>
>> Another possibility would be to make this more generic
>> and emit the instrumentation when we lower GIMPLE_BIND during
>> the GIMPLE lowering pass, you wouldn't then rely on the CLOBBERs
>> some of which only appear when -fstack-reuse=none is not used.
>
> The CLOBBERs that trigger on Firefox and LLVM are emitted not during
> gimplification, but via build_clobber_this in the front-end.
>
> Alexander
>
