[LLVMdev] IR extension proposal: bitset constants
JF Bastien
jfb at google.com
Sat Jan 31 14:53:40 PST 2015
>
> > 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).
Or maybe I'm being overly cautious when it comes to metadata's ability to
be dropped?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150131/28ef13b2/attachment.html>
More information about the llvm-dev
mailing list