Re: [PATCH V2 6/8] bpf: adjust GCC testsuite to eBPF limitations

[Jeff Law <law at redhat dot com>]

On 8/19/19 8:23 AM, Jose E. Marchesi wrote:
> 
>     [...]
>     > 	* gcc.dg/Wframe-larger-than-2.c: Likewise.
>     > 	* gcc.dg/Wframe-larger-than.c: Likewise.
>     > 	* gcc.dg/Wrestrict-11.c: Likewise.
>     So I think we probably want an effective target check for indirect calls
>     rather than checking explicitly for ebpf in all these files.
>     
> Ok, will introduce it.
> 
>     It also seems like rather than checking for ebpf on files with large
>     stacks, we should be using the generic mechanisms to defined the allowed
>     size of the stack (mentioned in prior review) & mark test which use too
>     much space.  This would almost certainly help other embedded targets as
>     well.
>     
> I first thought about doing that, but hesitated when I realized it would
> require to alter existing tests in no trivial ways: will the test still
> effectively test whatever it is supposed to test, after the size of an
> array is changed, for example?
I think you just add something like

/* dg-require-stack-size "<size>" */

Assuming that's right you don't have to worry about changing the test
itself and potentially changing its meaning.

I wouldn't necessarily try to figure the exact size needed by each test.
 A reasonable guesstimation ought to be sufficient.


> 
>     Not sure the best way to deal with too many arguments.  I suspect we
>     want an efffective target check for that.  Keeping this up-to-date will
>     be painful as people write more tests.
>     
> Yeah, that won't be fun :(
> 
>       /* Copyright (C) 2000, 2003 Free Software Foundation */
>     >  __complex__ long long f ()
>     > diff --git a/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
>     > b/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
>     > index be0bdcf7631..9f6bd0af2e5 100644
>     > --- a/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
>     > +++ b/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
>     > @@ -3,6 +3,7 @@
>     >  /* { dg-skip-if "too much code for pdp11" { "pdp11-*-*" } } */
>     >  /* { dg-xfail-if "PR36698" { spu-*-* } { "-O0" } { "" } } */
>     >  /* { dg-skip-if "" { m32c-*-* } } */
>     > +/* { dg-skip-if "jumps too far for eBPF" { bpf-*-* } } */
>     >  /* { dg-timeout-factor 4.0 } */
>     Jumps too far is probably an indication you need to fix something in
>     your port.  Though I guess its OK if you're never going to support far
>     away targets.
> 
> The reasons for this are that eBPF doesn't have indirect jump
> instructions, and the direct jump instruction's displacement is a signed
> PC-relative 16-bit offset, in 64-bit word units.
> 
> So, unless the compiler gets able to generate a "chain" of direct jumps
> to reach the destination (that would be a fun hack :D) the range for
> branches is severely limited.
OK.  Perhaps another effective target check.   Or leave this one with
the epf check.

jeff