llvm dev - Oct 2015 - Problem with intrinsic::trap insertion instead of null pointer dereference

Hi everyone,

Llvm detects zero pointer dereference in CFG simplify and insert intrinsic::trap
(at least with -O1 or -O2).
Problem 1 : I find it unfortunate not to be able to disable it, and allow a
specific target to handle it its own way (with MMU fault or dedicated HW
stuff).
>> Is there a trick to avoid this ?
Problem 2 : Unless special care is taken in LLVM backend, DAG select will fail
on trap, without a clear indication of the guilty C
fragment
>> Should the frontend emit at least a warning ?
Thanks for your help.

--
Fred

Example :
C code (many lines remove for the sake of clarity) :



struct s;

struct s{

                struct s *next;

};



struct s* foo (struct s *a){

                struct s *b = 0;

                b->next = a;

                return b;

}

LLVM (clang -O2 -emit-llvm) :



%struct.s = type { %struct.s* }



; Function Attrs: noreturn nounwind

define noalias %struct.s* @foo(%struct.s* nocapture readnone %a) #0 {

entry:

  tail call void @llvm.trap()

  unreachable

}



; Function Attrs: noreturn nounwind

declare void @llvm.trap() #1



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151021/9e79f071/attachment-0001.html>
-------------- next part --------------
An embedded message was scrubbed...
From: unknown sender
Subject: 
Date: Wed, 21 Oct 2015 12:42:53 +0000
Size: 1332
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151021/9e79f071/attachment-0004.mht>
-------------- next part --------------
An embedded message was scrubbed...
From: unknown sender
Subject: 
Date: Wed, 21 Oct 2015 12:38:15 +0000
Size: 592
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151021/9e79f071/attachment-0005.mht>
-------------- next part --------------
An embedded message was scrubbed...
From: unknown sender
Subject: How to disable intrinsic::trap automatic insertion 
Date: no date
Size: 45143
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151021/9e79f071/attachment-0006.mht>
-------------- next part --------------
An embedded message was scrubbed...
From: unknown sender
Subject: 
Date: no date
Size: 41329
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151021/9e79f071/attachment-0007.mht>

Sorry for meaningless attachments of drafts, Outlook strikes back.

--
fred

De : llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] De la part de
HEITZMANN Frédéric 218168 via llvm-dev
Envoyé : mercredi 21 octobre 2015 14:46
À : llvm-dev at lists.llvm.org
Cc : LLOPARD Ivan 222352 <Ivan.LLOPARD at cea.fr>
Objet : [llvm-dev] Problem with intrinsic::trap insertion instead of null
pointer dereference

Hi everyone,

Llvm detects zero pointer dereference in CFG simplify and insert intrinsic::trap
(at least with -O1 or -O2).
Problem 1 : I find it unfortunate not to be able to disable it, and allow a
specific target to handle it its own way (with MMU fault or dedicated HW
stuff).
>> Is there a trick to avoid this ?
Problem 2 : Unless special care is taken in LLVM backend, DAG select will fail
on trap, without a clear indication of the guilty C
fragment
>> Should the frontend emit at least a warning ?
Thanks for your help.

--
Fred

Example :
C code (many lines remove for the sake of clarity) :



struct s;

struct s{

                struct s *next;

};



struct s* foo (struct s *a){

                struct s *b = 0;

                b->next = a;

                return b;

}

LLVM (clang -O2 -emit-llvm) :



%struct.s = type { %struct.s* }



; Function Attrs: noreturn nounwind

define noalias %struct.s* @foo(%struct.s* nocapture readnone %a) #0 {

entry:

  tail call void @llvm.trap()

  unreachable

}



; Function Attrs: noreturn nounwind

declare void @llvm.trap() #1



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151021/6cdd2880/attachment.html>

On 21 October 2015 at 05:46, HEITZMANN Frédéric 218168
<llvm-dev at lists.llvm.org> wrote:
> Llvm detects zero pointer dereference in CFG simplify and insert
> intrinsic::trap (at least with –O1 or –O2).
>
> Problem 1 : I find it unfortunate not to be able to disable it, and allow a
> specific target to handle it its own way (with MMU fault or dedicated HW
> stuff).
>
>>> Is there a trick to avoid this ?
Not for Clang in general. This is a classic instance of C and C++'s
undefined behaviour. If you haven't seen them already, it would be a
good idea to read this series of blog posts:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

But the essence is that being able to do this kind of transformation
is essential for the performance of C programs.
> Problem 2 : Unless special care is taken in LLVM backend, DAG select will
> fail on trap, without a clear indication of the guilty C fragment
>
>>> Should the frontend emit at least a warning ?
The front-end can't know whether any given memory operation uses a
null pointer. Even where it does find out during compilation, it's
often only as a result of optimisations and we don't want the
diagnostics to depend on whether we're compiling at -O0 or -O3.

I believe Clang's static analysis mode would detect more of these problems.

Cheers.

Tim.