Re: Add support to trace comparison instructions and switch statements

[吴潍浠(此彼)]

Hi
I updated the patch and put it in attachment.

gcc/ChangeLog: 

2017-09-04  Wish Wu   

* asan.c (initialize_sanitizer_builtins):  
* builtin-types.def (BT_FN_VOID_UINT8_UINT8):  
(BT_FN_VOID_UINT16_UINT16):
(BT_FN_VOID_UINT32_UINT32):
(BT_FN_VOID_FLOAT_FLOAT):  
(BT_FN_VOID_DOUBLE_DOUBLE):
(BT_FN_VOID_UINT64_PTR):   
* common.opt:  
* flag-types.h (enum sanitize_coverage_code):  
* opts.c (COVERAGE_SANITIZER_OPT): 
(get_closest_sanitizer_option):
(parse_sanitizer_options): 
(common_handle_option):
* sancov.c (instrument_cond):  
(instrument_switch):   
(sancov_pass): 
* sanitizer.def (BUILT_IN_SANITIZER_COV_TRACE_CMP1):   
(BUILT_IN_SANITIZER_COV_TRACE_CMP2):   
(BUILT_IN_SANITIZER_COV_TRACE_CMP4):   
(BUILT_IN_SANITIZER_COV_TRACE_CMP8):   
(BUILT_IN_SANITIZER_COV_TRACE_CMPF):   
(BUILT_IN_SANITIZER_COV_TRACE_CMPD):   
(BUILT_IN_SANITIZER_COV_TRACE_SWITCH): 

gcc/testsuite/ChangeLog:   

2017-09-04  Wish Wu   

* gcc.dg/sancov/basic3.c: New test.

I think the aim of "trace-cmp" is finding reasonable values in runtime, playing 
approximate tricks when fuzzing.
We don't need to save all of values from low_case to high_case, there may be 
too much values and wasting resource.
For code :
void bar (void);
void
foo (int x)
{
  if (x == 21 || x == 64 || x == 98 || x == 135)
bar ();
}
GIMPLE IL on x86_64:
  1 
  2 ;; Function foo (foo, funcdef_no=0, decl_uid=2161, cgraph_uid=0, 
symbol_order=0)
  3 
  4 foo (int x)
  5 {
  6   unsigned int _5;
  7   unsigned int _6;
  8   unsigned int _7;
  9   unsigned int _8;
 10   unsigned int _9;
 11   unsigned int _10;
 12   unsigned int _11;
 13   unsigned int _12;
 14 
 15[0.00%] [count: INV]:
 16   _5 = (unsigned int) x_2(D);
 17   _6 = (unsigned int) 21;
 18   __builtin___sanitizer_cov_trace_cmp4 (_5, _6);
 19   if (x_2(D) == 21)
 20 goto ; [INV] [count: INV]
 21   else
 22 goto ; [INV] [count: INV]
 23 
 24[0.00%] [count: INV]:
 25   _7 = (unsigned int) x_2(D);
 26   _8 = (unsigned int) 64;
 27   __builtin___sanitizer_cov_trace_cmp4 (_7, _8);
 28   if (x_2(D) == 64)
 29 goto ; [INV] [count: INV]
 30   else
 31 goto ; [INV] [count: INV]
 32 
 33[0.00%] [count: INV]:
 34   _9 = (unsigned int) x_2(D);
 35   _10 = (unsigned int) 98;
 36   __builtin___sanitizer_cov_trace_cmp4 (_9, _10);
 37   if (x_2(D) == 98)
 38 goto ; [INV] [count: INV]
 39   else
 40 goto ; [INV] [count: INV]
 41 
 42[0.00%] [count: INV]:
 43   _11 = (unsigned int) x_2(D);
 44   _12 = (unsigned int) 135;
 45   __builtin___sanitizer_cov_trace_cmp4 (_11, _12);
 46   if (x_2(D) == 135)
 47 goto ; [INV] [count: INV]
 48   else
 49 goto ; [INV] [count: INV]
 50 
 51[0.00%] [count: INV]:
 52   bar ();
 53 
 54[0.00%] [count: INV]:
 55   return;
 56 
 57 }
 58 
 59
It actually catches reasonable and meaningful values. 
Maybe we can improve it in the future for tracing all of expression for 
comparison.

Wish Wu
--
From:Dmitry Vyukov 
Time:2017 Sep 3 (Sun) 19:05
To:Wish Wu 
Cc:Jakub Jelinek ; gcc ; gcc-patches 
; Jeff Law ; wishwu007 

Subject:Re: Add support to trace comparison instructions and switch statements


On Sun, Sep 3, 2017 at 12:38 PM, 吴潍浠(此彼)  wrote:
> Hi
> I will update the patch according to your requirements, and with some my 
> suggestions.
> It will take me one or two days.

Thanks! No hurry, just wanted to make sure you still want to pursue this.

> Wish Wu
>
> --
> From:Dmitry Vyukov 
> Time:2017 Sep 3 (Sun) 18:21
> To:Jakub Jelinek 
> Cc:Wish Wu ; gcc ; gcc-patches 
> ; Jeff Law ; wishwu007 
> 
> Subject:Re: Add support to trace comparison instructions and switch statements
>
>
> On Sun, Sep 3, 2017 at 12:19 PM, Dmitry Vyukov  wrote:
>> On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek  wrote:
>>> On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote:
 What we instrument in LLVM is _comparisons_ rather than control
 structures. So that would be:
 _4 

Re: assuming signed overflow does not occur

[Manuel López-Ibáñez]

On 03/09/17 23:00, Bruce Korb wrote:


RFE's are for this list: please improve the message.

The message does not have to be a dissertation, but messages
nowadays can certainly include URL's to direct people to
reasonable places. I'd suggest something like:

 gcc.gnu.org/gcc-messages/xxx

WRT looking at a GIMPLE dump, I'd first have to learn what GIMPLE is,
then learn how to decipher one, then figure out how to get it out of
the compiler and
finally plod through it. Guess what? I won't be doing that. I'll
squish the warning first. :(  Effective messages are very important.


I wrote an explanation of the current status of Wstrict-overflow to the best of 
my knowledge: https://gcc.gnu.org/wiki/VerboseDiagnostics#Wstrict_overflow


I didn't mention GIMPLE because it is often the case that the root of the 
problem is not obvious in gimple unless one also debugs the compiler at the 
same time.


I hope it is useful!

Cheers,

Manuel.

GNU Tools Cauldron 2017: OMP (Offloading and Multi Processing) BoF

[Thomas Schwinge]

Hi!

As Honza told me recently, it has been proposed by Martin -- I don't know
which one ;-) -- and certainly makes sense, to have another OMP
(Offloading and Multi Processing) BoF at the GNU Tools Cauldron 2017,
which is currently scheduled for Saturday, 11:00 to 11:45.  That is, a
general OMP BoF session in addition to more specific individual
presentations.

Honza volunteered me to host it ;-) -- to which I'm not immediately
objecting, but my time to prepare anything at all is very limited
(non-existing?) right now, and I still got to first organize stuff/myself
for my other presentation slot...

We could do it off the cuff, but it'd also be very useful to know
beforehand a handful of topics to talk about.  So, who's interested in
contributing to this OMP BoF?  I put some candidates in CC, but
everyone's welcome to contribute, of course!  I suggest this should
really be BoF-like: more interaction and discussion instead of too much
presentation.


Grüße
 Thomas

Re: GNU Tools Cauldron 2017: OMP (Offloading and Multi Processing) BoF

[Jan Hubicka]

> Hi!
> 
> As Honza told me recently, it has been proposed by Martin -- I don't know
> which one ;-) -- and certainly makes sense, to have another OMP
> (Offloading and Multi Processing) BoF at the GNU Tools Cauldron 2017,
> which is currently scheduled for Saturday, 11:00 to 11:45.  That is, a
> general OMP BoF session in addition to more specific individual
> presentations.
> 
> Honza volunteered me to host it ;-) -- to which I'm not immediately

To be precise, I also volunteered Martin (Jambor) to propose it.
In any case it seems it would be useful thing to have on programme. Let me
know if I should keep it there ;)

Honza
> objecting, but my time to prepare anything at all is very limited
> (non-existing?) right now, and I still got to first organize stuff/myself
> for my other presentation slot...
> 
> We could do it off the cuff, but it'd also be very useful to know
> beforehand a handful of topics to talk about.  So, who's interested in
> contributing to this OMP BoF?  I put some candidates in CC, but
> everyone's welcome to contribute, of course!  I suggest this should
> really be BoF-like: more interaction and discussion instead of too much
> presentation.
> 
> 
> Grüße
>  Thomas

Fwd: Assigning the result of a function call to a variable in the Gfortran frontend

[(IIIT) Siddharth Bhat]

Hello,

I've been hacking on the Gfortran frontend to change array index
expressions to function calls, so that I can inspect them later on in
the pipeline. I go from Fortran -> LLVM IR (through dragonegg) where I
will look at the function call nodes.

However, I'm not able to generate correct IR for this. I can create
function call, but I am unable to assign the return value of a
function call to a variable here.

Here's a link to my experiments here: It includes a patch, a test file
and the GIMPLE output -
https://gist.github.com/bollu/999184bdb3d0f1569ee0fd0a351689e3#file-m-gimple-L24

Help would be very much appreciated!

Thanks,
Siddharth.
-- 
Sending this from my phone, please excuse any typos!

Re: Bit-field struct member sign extension pattern results in redundant

[Michael Clark]

> On 19 Aug 2017, at 4:10 AM, Richard Henderson  wrote:
> 
> On 08/17/2017 03:29 PM, Michael Clark wrote:
>> hand coded x86 asm (no worse because the sar depends on the lea)
>> 
>>  sx5(int):
>>shl edi, 27
>>sar edi, 27
>>movsx eax, dl
> 
> Typo in the register, but I know what you mean.  More interestingly, edi
> already has the sign-extended value, so "mov eax, edi" sufficies (saving one
> byte or perhaps allowing better register allocation).
> 
> That said, if anyone is tweaking x86-64 patterns on this, consider
> 
> sx5(int):
>   rorxeax, edi, 5
>   sar eax, 27
> 
> where the (newish) bmi2 rorx instruction allows the data to be moved into 
> place
> while rotating, avoiding the extra move entirely.

The patterns might be hard to match unless we can get the gimple expansions for 
bitfield access to use the mode of the enclosing type.

For bitfield accesses to SI mode fields under 8 bits on RISC-V, gcc is 
generating two shifts on QI mode sub-registers, each with a sign-extend.

For bitfield accesses to SI mode fields under 16 bits on RISC-V, gcc is 
generating two shifts on HI mode sub-registers, each with a sign-extend.

The bitfield expansion logic is selecting the narrowest type that can hold the 
bitwidth of the field, versus the bitwidth of the enclosing type and this 
appears to be in the gimple to rtl transform, possibly in expr.c.

Using the mode of the enclosing type for bitfield member access expansion would 
likely solve this problem. I suspect that with the use of caches and word sized 
register accesses, that this sort of change would be reasonable to make for 
32-bit and 64-bit targets.

I also noticed something I didn’t spot earlier. On RV32 the sign extend and 
shifts are correctly coalesced into 27 bit shifts in the combine stage. We are 
presently looking into another redundant sign extension issue on RV64 that 
could potentially be related. It could be that the shift coalescing 
optimisation doesn’t happen unless the redundant sign extensions are eliminated 
early in combine by simplify_rtx. i.e. the pattern is more complex due to 
sign_extend ops that are not eliminated.

- https://cx.rv8.io/g/2FxpNw

RV64 and Aarch64 both appear to have the issue but with different expansions 
for the shift and extend pattern due to the mode of access (QI or HI). Field 
accesses above 16 bits create SI mode accesses and generate the expected code. 
The RISC-V compiler has the #define SLOW_BYTE_ACCESS 1 patch however it appears 
to make no difference in this case. SLOW_BYTE_ACCESS suppresses QI mode and HI 
mode loads in some bitfield test cases when a struct is passed by pointer but 
has no effect on this particular issue. This shows the codegen for the fix to 
the SLOW_BYTE_ACCESS issue. i.e. proof that the compiler as SLOW_BYTE_ACCESS 
defined to 1.

- https://cx.rv8.io/g/TyXnoG

A target independent fix that would solve the issue on ARM and RISC-V would be 
to access bitfield members with the mode of the bitfield member's enclosing 
type instead of the smallest mode that can hold the bitwidth of the type. If we 
had a char or short member in the struct, I can understand the use of QI and HI 
mode, as we would need narrorwer accesses due to alignment issues, but in this 
case the member is in int and one would expect this to expand to SI mode 
accesses if the enclosing type is SI mode.


riscv64:

sx5(int):
  slliw a0,a0,3
  slliw a0,a0,24
  sraiw a0,a0,24
  sraiw a0,a0,3
  ret

sx17(int):
  slliw a0,a0,15
  sraiw a0,a0,15
  ret

riscv32:

sx5(int):
  slli a0,a0,27
  srai a0,a0,27
  ret

sx17(int):
  slli a0,a0,15
  srai a0,a0,15
  ret

aarch64:

sx5(int):
  sbfiz w0, w0, 3, 5
  asr w0, w0, 3
  ret

sx17(int):
  sbfx w0, w0, 0, 17
  ret

Re: DragonEgg for GCC v8.x and LLVM v6.x is just able to work

[Leslie Zhai]

Hi LLVM and GCC developers,

LLVM China  http://www.llvm.org.cn  forked DragonEgg 
https://github.com/LLVM-China/dragonegg  because:


* Some subprojects are impractical or uninteresting to relicense (e.g. 
llvm-gcc  and dragonegg). These will be split off from the LLVM project 
(e.g. to separate Github projects), allowing interested people to 
continue their development elsewhere. 
http://lists.llvm.org/pipermail/llvm-dev/2017-August/116266.html


* There are a lot of issues 
https://github.com/xiangzhai/dragonegg/issues  so I need smarter 
developers' help.



在 2017年08月21日 11:31, Leslie Zhai 写道:

Hi LLVM and GCC developers,

My sincere thanks will goto:

* Duncan, the core developer of llvm-gcc and dragonegg 
http://llvm.org/devmtg/2009-10/Sands_LLVMGCCPlugin.pdf


* David, the innovator and developer of GCC 
https://dmalcolm.fedorapeople.org/gcc/global-state/requirements.html


and others who give me kind response for teaching me patiently and 
carefully about how to migrate GCC v4.8.x to GCC v8.x (git-20170818)


DragonEgg has been migrated to GCC v8.x and LLVM v6.x (svn-r311142), 
but also able to work for GCC v4.8.x and LLVM v3.3 
https://reviews.llvm.org/D35667 and it is just able to work now, for 
example:



CC=/opt/gcc-git/bin/gcc

LC=/opt/llvm-svn/bin/llvm-config

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$($LC --libdir)

GCC=$CC LLVM_CONFIG=$LC ENABLE_LLVM_PLUGINS=1 DRAGONEGG_DEBUG=1 make -j4


$CC -fplugin=./dragonegg.so \
-fplugin-arg-dragonegg-debug-pass-arguments \
-ftime-report \
-fverbose-asm \
-fplugin-arg-dragonegg-enable-gcc-optzns \
-fplugin-arg-dragonegg-emit-ir \
-S \
test/hello.c \
-wrapper gdb,--args


hello.s (LLVM IR, the extension name is not important)

; ModuleID = 'test/hello.c'
source_filename = "test/hello.c"
target triple = "x86_64-redhat-linux"

module asm "\09.ident\09\22GCC: (GNU) 6.4.1 20170727 (Red Hat 6.4.1-1) 
LLVM: 3.9.1\22"


@__func__.2210 = internal local_unnamed_addr constant [4 x i8] c"foo\00"
@.cst = private local_unnamed_addr constant [24 x i8] c"DEBUG: %s, 
line %d: %s\0A\00", align 8
@.cst.1 = private local_unnamed_addr constant [13 x i8] 
c"test/hello.c\00", align 8
@.cst.2 = private local_unnamed_addr constant [12 x i8] c"Leslie 
Zhai\00", align 8
@.cst.3 = private local_unnamed_addr constant [20 x i8] c"%s: Hello 
World %d\0A\00", align 8


; Function Attrs: nounwind uwtable
define void @foo(...) unnamed_addr #0 {
entry:
  %"ssa point" = bitcast i32 0 to i32
  br label %""

"": ; preds = %entry
  %0 = call i32 (i8*, ...) @printf(i8* noalias getelementptr inbounds 
([24 x i8], [24 x i8]* @.cst, i64 0, i64 0), [13 x i8]* @.cst.1, i32 
4, [4 x i8]* @__func__.2210) #1

  br label %return

return:   ; preds = %""
  ret void
}

declare i32 @printf(i8*, ...)

; Function Attrs: nounwind uwtable
define i32 @main(i32 %argc, i8** %argv) unnamed_addr #0 {
entry:
  %argc_addr = alloca i32, align 4
  %argv_addr = alloca i8**, align 8
  %n = alloca i32
  %s = alloca i8*
  %"" = alloca i32
  %"alloca point" = bitcast i32 0 to i32
  store i32 %argc, i32* %argc_addr, align 1
  store i8** %argv, i8*** %argv_addr, align 1
  %"ssa point" = bitcast i32 0 to i32
  br label %""

"": ; preds = %entry
  %0 = call i32 (i8*, ...) @printf(i8* noalias getelementptr inbounds 
([20 x i8], [20 x i8]* @.cst.3, i64 0, i64 0), i8* getelementptr 
inbounds ([12 x i8], [12 x i8]* @.cst.2, i64 0, i64 0), i32 1) #1

  br label %""

"":   ; preds = %""
  store i32 0, i32* %"", align 1
  br label %return

return:   ; preds = %""
  %1 = load i32, i32* %"", align 4
  ret i32 %1
}

attributes #0 = { nounwind uwtable 
"no-frame-pointer-elim-non-leaf"="true" }

attributes #1 = { nounwind }

!llvm.module.flags = !{!0}

!0 = !{i32 1, !"PIE Level", i32 2}


$ llc hello.s

.text
.file"hello.s"
# Start of file scope inline 
assembly

.ident"GCC: (GNU) 6.4.1 20170727 (Red Hat 6.4.1-1) LLVM: 3.9.1"

# End of file scope inline 
assembly

.globlfoo
.p2align4, 0x90
.typefoo,@function
foo:# @foo
.cfi_startproc
# BB#0: # %entry
pushq%rbp
.Ltmp0:
.cfi_def_cfa_offset 16
.Ltmp1:
.cfi_offset %rbp, -16
movq%rsp, %rbp
.Ltmp2:
.cfi_def_cfa_register %rbp
movl$.L.cst, %edi
movl$.L.cst.1, %esi
movl$4, %edx
movl$__func__.2210, %ecx
xorl%eax, %eax
callqprintf
popq%rbp
retq
.Lfunc_end0:
.sizefoo, .Lfunc_end0-foo
.cfi_endproc

.globlmain
.p2align4, 0x90
.typemain,@function
main:   # @main
.cfi_startproc
# BB#0:  

Re: Assigning the result of a function call to a variable in the Gfortran frontend

[Tobias Grosser]

Hi Leslie,

I copied you in this thread as you currently worked quite a bit with
dragonegg and we are currently trying to generate metadata that makes it
easier to reason about multi-dimensional fortran arrays.

Best,
Tobias

On Mon, Sep 4, 2017, at 23:06, (IIIT) Siddharth Bhat wrote:
> Hello,
> 
> I've been hacking on the Gfortran frontend to change array index
> expressions to function calls, so that I can inspect them later on in the
> pipeline. I go from Fortran -> LLVM IR (through dragonegg) where I will
> look at the function call nodes.
> 
> However, I'm not able to generate correct IR for this. I can create
> function call, but I am unable to assign the return value of a function
> call to a variable here.
> 
> Here's a link to my experiments here: It includes a patch, a test file
> and
> the GIMPLE output
> 
> .
> 
> Help would be very much appreciated!
> 
> Thanks,
> Siddharth.
> -- 
> Sending this from my phone, please excuse any typos!