> From:
> Date: Tue, 24 Oct 2023 17:11:24 +0300
> From: Daniil Frolov
>
> PR 66487 is asking to provide sanitizer-like detection for C++ object lifetime
> violations that are worked around with -fno-lifetime-dse in Firefox, LLVM,
> OpenJade.
>
> The discussion in the PR was centered around
On Tue, Nov 21, 2023 at 9:56 AM Alexander Monakov wrote:
>
>
> On Tue, 21 Nov 2023, Richard Biener wrote:
>
> > and this, too, btw. - the DSE actually happens, the latter transform not.
> > We specifically "opt out" of doing that for QOI to not make undefined
> > behavior worse. The more correct
On Tue, 21 Nov 2023, Richard Biener wrote:
> and this, too, btw. - the DSE actually happens, the latter transform not.
> We specifically "opt out" of doing that for QOI to not make undefined
> behavior worse. The more correct transform would be to replace the
> load with a __builtin_trap ()
On Tue, Nov 21, 2023 at 8:59 AM Alexander Monakov wrote:
>
>
> On Tue, 21 Nov 2023, Alexander Monakov wrote:
>
> > I am concerned that if GCC ever learns to leave out the following access
> > to 'this->foo', leaving tmp uninitialized, we will end up with:
> >
> > this->foo = 42;
>
> Sorry,
On Tue, 21 Nov 2023, Alexander Monakov wrote:
> I am concerned that if GCC ever learns to leave out the following access
> to 'this->foo', leaving tmp uninitialized, we will end up with:
>
> this->foo = 42;
Sorry, this store will be DSE'd out, of course, but my question stands.
On Mon, 13 Nov 2023, Richard Biener wrote:
> > 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
On 2023-11-13 02:53, Sam James wrote:
Sam James writes:
Alexander Monakov writes:
[...]
I'm very curious what you mean by "this has come up with LLVM []
too": ttbomk,
LLVM doesn't do such lifetime-based optimization yet, which is why
compiling
LLVM with LLVM doesn't break it. Can you
> Am 13.11.2023 um 15:52 schrieb Alexander Monakov :
>
>
>> 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
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
On Tue, Oct 24, 2023 at 4:12 PM wrote:
>
> From: Daniil Frolov
>
> PR 66487 is asking to provide sanitizer-like detection for C++ object lifetime
> violations that are worked around with -fno-lifetime-dse in Firefox, LLVM,
> OpenJade.
>
> The discussion in the PR was centered around extending
Sam James writes:
> Alexander Monakov writes:
> [...]
>>
>> I'm very curious what you mean by "this has come up with LLVM [] too":
>> ttbomk,
>> LLVM doesn't do such lifetime-based optimization yet, which is why compiling
>> LLVM with LLVM doesn't break it. Can you share some examples? Or do
Alexander Monakov writes:
> On Sat, 11 Nov 2023, Sam James wrote:
>
>> > Valgrind client requests are offered as macros that emit inline asm. For
>> > use
>> > in code generation, we need to wrap it in a built-in. We know that
>> > implementing
>> > such a built-in in libgcc is
On Sat, 11 Nov 2023, Sam James wrote:
> > Valgrind client requests are offered as macros that emit inline asm. For
> > use
> > in code generation, we need to wrap it in a built-in. We know that
> > implementing
> > such a built-in in libgcc is undesirable, [...].
>
> Perhaps less
On Sat, 11 Nov 2023, Arsen Arsenović wrote:
> > +#else
> > +# define VALGRIND_MAKE_MEM_UNDEFINED(ptr, sz) __builtin_trap ()
> > +#endif
> > +
> > +void __valgrind_make_mem_undefined (void *ptr, unsigned long sz)
> > +{
> > + VALGRIND_MAKE_MEM_UNDEFINED (ptr, sz);
> > +}
>
> Would it be
exactl...@ispras.ru writes:
> From: Daniil Frolov
>
> PR 66487 is asking to provide sanitizer-like detection for C++ object lifetime
> violations that are worked around with -fno-lifetime-dse in Firefox, LLVM,
> OpenJade.
>
> The discussion in the PR was centered around extending MSan, but
Hi,
I like the idea of emitting Valgrind annotations. Instrumenting the
compiler /a little/ could make a very useful tool even more useful.
I have a minor remark, though (as someone not qualified to talk about
the middle-end bits of code), in the case that the annotation built-in
remains a
From: Daniil Frolov
PR 66487 is asking to provide sanitizer-like detection for C++ object lifetime
violations that are worked around with -fno-lifetime-dse in Firefox, LLVM,
OpenJade.
The discussion in the PR was centered around extending MSan, but MSan was not
ported to GCC (and requires
17 matches
Mail list logo
