search for: d7288

Displaying 5 results from an estimated 5 matches for "d7288".

Did you mean: 97288
2015 Jan 30
3
[LLVMdev] IR extension proposal: bitset constants
On Thu, Jan 29, 2015 at 02:22:48PM -0800, Peter Collingbourne wrote: > I've been working on a patch that implements the bitset attribute and bitset > lowering pass. I'll see if I can send it out later today. http://reviews.llvm.org/D7288 Thanks, -- Peter
2015 Jan 30
0
[LLVMdev] IR extension proposal: bitset constants
...at pcc.me.uk> wrote: > > On Thu, Jan 29, 2015 at 02:22:48PM -0800, Peter Collingbourne wrote: >> I've been working on a patch that implements the bitset attribute and bitset >> lowering pass. I'll see if I can send it out later today. > > http://reviews.llvm.org/D7288 <http://reviews.llvm.org/D7288> Hi Peter, I don’t think that adding an IR construct for this is the way to go. You’re making IR complicated for everyone to serve a very narrow use case (one that admittedly I don’t really understand). The fact that this affects semantics and will only work...
2015 Jan 29
0
[LLVMdev] IR extension proposal: bitset constants
On Thu, Jan 29, 2015 at 12:16:58PM +0000, Renato Golin wrote: > On 29 Jan 2015 11:36, "Sean Silva" <chisophugis at gmail.com> wrote: > > > > > > > > On Thu, Jan 29, 2015 at 12:53 AM, Renato Golin <renato.golin at linaro.org> > wrote: > >> > >> So, bitset would be a property that means : globals with the same name > will
2015 Jan 29
2
[LLVMdev] IR extension proposal: bitset constants
On 29 Jan 2015 11:36, "Sean Silva" <chisophugis at gmail.com> wrote: > > > > On Thu, Jan 29, 2015 at 12:53 AM, Renato Golin <renato.golin at linaro.org> wrote: >> >> So, bitset would be a property that means : globals with the same name will append on a string of bits in the order in which they appear, and it's the job of the front end to make sure
2015 Feb 01
2
[LLVMdev] IR extension proposal: bitset constants
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