[LLVMdev] IR extension proposal: bitset constants

[Peter Collingbourne]

On Sat, Jan 31, 2015 at 02:53:40PM -0800, JF Bastien wrote:
> >
> > > The one think we need to ensure is that your metadata can be dropped by
> > the
> > > optimizer and the code remains correct. I'm guessing no vtable would mean
> > > anything goes (not check)? That's bad security-wise, but it'll at least
> > > work. We may want to make sure nothing gets dropped through a debug flag,
> > > so that we can compile Chrome and be confident that all the checks we
> > want
> > > are there.
> >
> > So the flag would determine whether no bitset present means return 1 or
> > return 0? Sounds reasonable.
> 
> 
> I'd keep it generating the same code, but have a debug output when the
> debug flag is on. My reasoning is that this wouldn't happen if your feature
> were a first-class IR construct, but because it's in the let's-try-it-out
> metadata phase it needs to "just work" when metadata is dropped. Yours
> being a security-oriented feature we'd want to be able to sanity-check that
> things compiled as expected for users who care (like Chrome). Once the
> feature graduates to IR instead of metadata it would be expected to always
> be correct security-wise (never silently drop information).

Okay, makes sense.

> Or maybe I'm being overly cautious when it comes to metadata's ability to
> be dropped?

As far as I am aware, only instruction-level metadata can be dropped entirely.
Module-level metadata stays mostly intact, but references to globals in
metadata can be replaced with nulls if the global is dropped.

The current behavior suits our purposes, but I can't find anywhere where any of
this behavior is specified, and it's entirely possible that it may change. The
flag that you propose would be a useful guard against that possibility.

Thanks,
-- 
Peter