[llvm-dev] Full restrict support - status update

Finkel, Hal J. via llvm-dev llvm-dev at lists.llvm.org
Tue Oct 29 12:34:48 PDT 2019

On 10/29/19 2:25 PM, Roman Lebedev via llvm-dev wrote:
> On Tue, Oct 29, 2019 at 9:26 PM David Greene via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Jeroen Dobbelaere via llvm-dev <llvm-dev at lists.llvm.org> writes:
>>> - the 'SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-pr38212.test'  in the 'test-suite' fails:
>>> -- the test is wrong as it triggers undefined behavior: it reads and writes the same object through 2 different
>>>      restrict pointers which have been declared in the same scope.
>> What's the failure mode?  Wrong answers or compiler abort?  If the
>> latter,
>> it would be nice if LLVM could emit a warning about illegal use
>> of restrict.  Longer term, a RestrictSanitizer would be really helpful.
> Yes :)
> I would think it would not require any runtime (think - asan/msan) support,
> so i'm not sure why it could not be a part of UBSan proper.
> In other words i'd like to *tentatively* claim this,
> i may be interested to look into it, after the restrict support lands :)


I'm not sure, however, how you do this without a runtime and shadow 
memory. You need to add some dynamic data-flow analysis to determine 
which pointers are based on which restrict-qualified pointers. This, in 
addition to in-function instrumentation, needs some side channel to deal 
with function calls (because you need to pass this information across 
the function-call interface and it's not clear to me that changing the 
ABI is generally practical) and values stored in memory (which likely 
need shadow member). Then, for each byte of memory, you need to keep 
track of which have been accessed by pointers based on 
restrict-qualified pointers, which restrict-qualified pointers, and 
appropriately clear out that data when the associated restrict-qualified 
pointer goes out of scope.


>>                        -David
> Roman
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

More information about the llvm-dev mailing list