Re: [PATCH 0/8] eBPF support for GCC

2019-08-15 Thread Jose E. Marchesi


Hi Richard.

> . Dynamic stack allocation (alloca and VLAs) is achieved by using what
>   otherwise would be a perfectly normal general register, %r9, as a
>   pseudo stack pointer.  This has the disadvantage of making the
>   register "fixed" and therefore not available for general register
>   allocation.  Hopefully there is a way to conditionalize this, since
>   both alloca and VLAs are relatively uncommon; I haven't found it
>   yet.

In principle it's possible to define register eliminations for
target-specific registers as well as the usual
FRAME/ARG_POINTER_REGNUM crowd.

Yeah, before I started using %r9 as a stack pointer, I was indeed
"eliminating" a fake stack pointer hard register to the frame register,
i.e. the opposite of what is usually done.

That seemed to work well, but as soon as __builtin_alloca and/or VLAs
were used, lra-eliminations would enter into an infinite loop: it didn't
like the stack pointer being eliminated.

So you could have a fake fixed register to represent the pseudo
stack pointer, then allow that to be "eliminated" to %r9 in
functions that need it.  Functions that don't need it can continue
(not) using the fake register and leave %r9 free for general use.

Interesting idea...  but wouldn't that require to have %r9 declared as a
fixed register, in functions that cfun->calls_alloca?

After reading your reply I investigated a bit, and found out that
CONDITIONAL_REGISTER_USAGE can indeed be called at pleasure, via
reinit_regs(). The i386 port calls reinit_regs in set_current_function,
for example.

So it should be possible to declare %r9 as fixed or non-fixed, in
bpf_set_current_function, depending on the value of
cfun->calls_alloca...


Re: [PATCH 0/8] eBPF support for GCC

2019-08-15 Thread Richard Sandiford
"Jose E. Marchesi"  writes:
> . Dynamic stack allocation (alloca and VLAs) is achieved by using what
>   otherwise would be a perfectly normal general register, %r9, as a
>   pseudo stack pointer.  This has the disadvantage of making the
>   register "fixed" and therefore not available for general register
>   allocation.  Hopefully there is a way to conditionalize this, since
>   both alloca and VLAs are relatively uncommon; I haven't found it
>   yet.

In principle it's possible to define register eliminations for
target-specific registers as well as the usual FRAME/ARG_POINTER_REGNUM
crowd.  So you could have a fake fixed register to represent the pseudo
stack pointer, then allow that to be "eliminated" to %r9 in functions
that need it.  Functions that don't need it can continue (not) using the
fake register and leave %r9 free for general use.

Richard


Re: [PATCH 0/8] eBPF support for GCC

2019-08-14 Thread Jose E. Marchesi


> The second patch adds the new GCC port proper.  Machine description,
> implementation of target hooks and macros, command-line options and
> the like.

Looks like [PATCH 2/8] didn't make it to the mailing list for some
reason (maybe it exceeded a size limit?)

Yeah the Oracle smtpmail server seems to not be routing 2/8... how
annoying.  I just sent it again using my GNU account.


Re: [PATCH 0/8] eBPF support for GCC

2019-08-14 Thread David Malcolm
On Wed, 2019-08-14 at 23:36 +0200, Jose E. Marchesi wrote:
> Hi people!
> 

[...]

> The second patch adds the new GCC port proper.  Machine description,
> implementation of target hooks and macros, command-line options and
> the like.

Looks like [PATCH 2/8] didn't make it to the mailing list for some
reason (maybe it exceeded a size limit?)

[...]

Dave