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