This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH V2 2/8] bpf: new GCC port


On Tue, Aug 20, 2019 at 03:42:53PM -0600, Jeff Law wrote:
> > I have been thinking about Segher's suggestion on providing options to
> > lift some of the limitations, for compiler testing.  Unfortunately, many
> > of the restrictions are deeply rooted in the design of the
> > architecture... or the other way around.  Finding sane ways to implement
> > these extensions will be fun :)
> Hell, it's a virtual architecture.  I'd just make up new instructions
> for the missing functionality, make them dependent on an flag.  I think
> the PRU is in a similar position and uses that approach.  PTX might have
> as well.

This approach works well for simulators for physical architectures, too.

> > This may change at some point.  There is much discussion among the
> > kernel hackers in whether it is possible to allow bounded loops in a
> > safe way.  In that case, some of the restrictions may be lifted.
> ACK.  It's an interesting problem.  Would it help if we could annotate
> loops with bound information?  Not sure how to preserve that from gimple
> down to assembly, but it's worth pondering.

You probably should have machine insns that iterate a loop some number of
times given when you first start the loop (and cannot be changed later,
except maybe exiting from the loop).  Like "doloop" in GCC.  Maybe only
allow a constant number of times, if the verifier want to see that?

The only thing the verifier should be concerned with is how long the code
takes to run, or am I missing something?


Segher


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]