[llvm-commits] [Review] Attributes Documentation

[James Molloy]

I don't think there's any need to enforce an order. Attribute groups are
sets, and equivalence over sets is trivial; I don't see what else is
needed?

It should be enough to specify that no two attribute groups can have the
same set of attributes.

On Wed, 2012-12-05 at 09:50 +0000, Renato Golin wrote:
> On 5 December 2012 08:56, James Molloy <James.Molloy at arm.com> wrote:
> > How does uniquing work?
> >
> > attributes #0 = { noinline optsize }
> > attributes #1 = { noinline optsize }
>
> I was wondering about the same thing. Luckily, this is easily worked
> around, like commoning up types, provided the order is forced, ie. it
> should not be possible to have:
>
> attributes #0 = { noinline optsize }
> attributes #1 = { optsize noinline }
>
> Making the attributes as classes / enum objects is one way to do it.
> It loses the flexibility of adding new attributes, but shouldn't be
> too hard to add a new item on an enum (or a new small class) on a
> common header.
>
>
>
> However, a much worse problem is packing. The number of possible
> combinations is huge, and simplifying them is an np-complete problem.
>
> attributes #0 = { noinline optsize }
> attributes #1 = { no-sse alignstack=4 }
>
> define void @f() #0 #1 { ... }
>
> // Here, if I want optsize + alignstack=4, I need to create another
>
> attributes #2 = { optsize alignstack=4 }
>
> define void @f2() #2 { ... }
>
> // What if I want no-sse AND noinline?
>
> attributes #3 = { no-sse noinline }
>
> define void @f3() #3 { ... }
>
> // Now, I want a combination of { noinline optsize alignstack=4 },
> which do I use?
>
> define void @f4() #0 #2 { ... } // is the answer, but how computers find this?
>
> The problem is, for every new function, you'll have to search the
> whole space for the best match among all combinations of all declared
> attributes, or just create a new one if there isn't any *exactly* as
> you want.
>
> The first solution is np-complete, the second will bloat code. I
> believe, the whole point of this change is to reduce IR footprint.
>
>
>
> I personally think that having the attributes on the functions is
> *much* better, on the textual form, than having to check them
> somewhere else in the IR.
>
> So, my humble opinion is that this should be a pass only executed in
> binary form, *after* IR has been formed (with attributes on
> functions), and the pass gathers all possible attributes, generates a
> group of the common cases and replace attributes list with a pointer
> to the list, which is commoned up somewhere else. No need for changing
> the textual form, that is mainly directed to humans, not computers.
>
>
> --
> cheers,
> --renato
>
> http://systemcall.org/
>


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.