Displaying 4 results from an estimated 4 matches for "retconning".
Did you mean:
rescanning
2018 Jan 10
3
RFC: attribute synthetic("reason")
Summary
I would like to propose that we add the following function attribute to LLVM:
synthetic(<string>)
This attribute can only be applied to functions. It is not a semantic statement about the function it decorates. It is, instead, an explicit directive to LLVM to not attempt to propagate information about the function body outside of the function, including by changing the
2018 Jan 12
0
RFC: attribute synthetic("reason")
That all makes sense.
I don't think the name "synthetic" is all that intuitive, though. Enum
attributes are pretty cheap, maybe we should try to use a name closer to
what we're trying to implement? For example, we could add a new
"coroutine_foo" attribute for every coroutine style we implement. We
would have analysis helper functions to answer questions like "is
2010 May 11
4
Fwd: Skeleton 4.0 draft, help with Dirac fields please!
On 10 May 2010 23:20, Chris Pearce <chris at pearce.org.nz> wrote:
> The granulepos radix was something that Conrad and Ralph were talking about
> at FOMS2010. I don't know how it's supposed to be used, or why we need it.
> It was supposed to be needed for Dirac? Maybe Ralph or Conrad can remember?
> If not, we should remove it. There's no point in adding a poorly
2018 Jan 10
0
RFC: attribute synthetic("reason")
(Forwarding response to llvm-dev with Dave's permission.)
> On Jan 10, 2018, at 11:19 AM, David Blaikie <dblaikie at gmail.com> wrote:
> Optnone stops these things, doesnt it? But then, as you say, you'd have to find some way to tunnels true optnone through to the coroutine expansion pass.
>
Right. More importantly, we definitely want to allow internal optimization of the