search for: sspreq

...ttributes: !1 = metadata !{ !"noinline", !2 } !2 = metadata !{ !1, !"ssp" } This makes uniquifying the attributes that much harder. We also want to be able to intelligently merge the attribute groups. These two groups are identical: #1 = attributes { noredzone noinline sspreq "mcpu"="cortex-a8" } #2 = attributes { "mcpu"="cortex-a8" sspreq noinline noredzone } Which brings up the '<kind>=<value>' syntax. The ability to have (possibly multiple) values assigned to an attribute kind isn't something easily m...

...--------- The bulk of the work required for stack-protector-strong is already implemented for the existing stack-protector support. The proposed work is: 1 Adding a new IR attribute "sspstrong": ssp - SSP on, use basic heuristic sspstrong - SSP on, use strong heuristic sspreq - SSP on, required for function - Note, I am proposing the IR attribute because it fits nicely into the existing structure. An alternative choice would be to add a new CodeGen option that would cause ssp-specified functions to be analyzed using the strong heuristic. I pre...

...uot;noinline", !2 } > !2 = metadata !{ !1, !"ssp" } > > This makes uniquifying the attributes that much harder. > > We also want to be able to intelligently merge the attribute groups. These two groups are identical: > > #1 = attributes { noredzone noinline sspreq "mcpu"="cortex-a8" } > #2 = attributes { "mcpu"="cortex-a8" sspreq noinline noredzone } > > Which brings up the '<kind>=<value>' syntax. The ability to have (possibly multiple) values assigned to an attribute kind isn't som...

...r the language changes. There isn't a lot of new information except for the syntax changes for the new feature. Executive Summary: The new syntax is: #0 = attributes { noinline align=4 "cpu"="cortex-a8" } #1 = attributes { attr = (val1 val2 val3) } #bork = attributes { sspreq noredzone } define void @foo() #0 #bork { ret void } The 'align' and "cpu" attributes both have a value associated with them. The 'attr' attribute in '#1' has multiple values associated with it. (The BNF is below in the 'IR Changes' section.) Attribute g...

...!2 = metadata !{ !1, !"ssp" } >> >> This makes uniquifying the attributes that much harder. >> >> We also want to be able to intelligently merge the attribute groups. >> These two groups are identical: >> >> #1 = attributes { noredzone noinline sspreq "mcpu"="cortex-a8" } >> #2 = attributes { "mcpu"="cortex-a8" sspreq noinline noredzone } >> >> Which brings up the '<kind>=<value>' syntax. The ability to have >> (possibly multiple) values assigned to an attribu...

...uired for stack-protector-strong is already implemented > for the existing stack-protector support. > The proposed work is: > 1 Adding a new IR attribute "sspstrong": > ssp - SSP on, use basic heuristic > sspstrong - SSP on, use strong heuristic > sspreq - SSP on, required for function > - Note, I am proposing the IR attribute because it fits nicely into the > existing structure. An alternative choice would be to add a new CodeGen > option that would cause ssp-specified functions to be analyzed using the >...

On Jan 29, 2013, at 2:42 PM, Bill Wendling <isanbard at gmail.com> wrote: > Executive Summary: > > The new syntax is: > > #0 = attributes { noinline align=4 "cpu"="cortex-a8" } > #1 = attributes { attr = (val1 val2 val3) } > #bork = attributes { sspreq noredzone } > > define void @foo() #0 #bork { ret void } The general syntax LGTM. It seems clean and fits well with what we have. > The 'align' and "cpu" attributes both have a value associated with them. The 'attr' attribute in '#1' has multiple valu...

...l Wendling <isanbard at gmail.com> wrote: >> Executive Summary: >> >> The new syntax is: >> >> #0 = attributes { noinline align=4 "cpu"="cortex-a8" } >> #1 = attributes { attr = (val1 val2 val3) } >> #bork = attributes { sspreq noredzone } >> >> define void @foo() #0 #bork { ret void } > > The general syntax LGTM. It seems clean and fits well with what we have. > Thanks! :-) >> The 'align' and "cpu" attributes both have a value associated with them. The 'attr' a...

Hi Bill, On 30/12/12 03:21, Bill Wendling wrote: > Hi Rafael, > > Sorry, I forgot to respond to this. They can be arbitrary strings that are known only to the specific back-end. It may be beneficial to define them inside of the LangRef document though. this sounds so much like metadata... What was the reason for not enhancing metadata to cover this use case? I'm sure you explained

...ample: >> >> What is the use case for the multi-value attribute? Perhaps obvious, but it makes sense to stage this out to add one thing at a time. Also, your BNF doesn't make it clear what is allowed for <value>: I would assume it is a set of hardcoded keywords (like align, sspreq, etc) plus the string form. If so, how does "val1" fit into that? >> > I added it because I wanted to limit possible future changes to the IR. But that may be premature. It would essentially act like the '-mattr' command line option works today. Of course the -mattr fun...

Hi Rafael, Sorry, I forgot to respond to this. They can be arbitrary strings that are known only to the specific back-end. It may be beneficial to define them inside of the LangRef document though. -bw On Oct 4, 2012, at 7:47 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> attrgroup #1 = { "long-calls", "cpu=cortex-a8", "thumb" }

...er-rt (r220991). The same changes are also available on https://github.com/cpi-llvm <http://github.com/cpi-llvm> in the safestack-r221153 branches of corresponding repositories. The patches make the following changes: -- Add the safestack function attribute, similar to the ssp, sspstrong and sspreq attributes. -- Add the SafeStack instrumentation pass that applies the safe stack to all functions that have the safestack attribute. This pass moves all unsafe local variables to the unsafe stack with a separate stack pointer, whereas all safe variables remain on the regular stack that is managed...