search for: noredzon

...loop" in the attributes: !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 s...

Hello, David >> Don't do that (tm) > > Why not? They will be eliminated w/o any visible effect. >> I'm testing the fix. > > Ok, I'll try to "mark noredzone" thing and see if that works. It does, I verified this with the testcase you attached to PR. The problem is not stack allocation, but red zone thing. As I already said, I'm testing the fix; since it touches some target independent code as well, I need to be sure that I haven't screwed...

...Private | Dllimport | Dllexport | External_weak | Ghost + | Common + | Linker_private end module Visibility = struct @@ -79,6 +84,15 @@ | Nest | Readnone | Readonly + | Noinline + | Alwaysinline + | Optforsize + | Stackprotect + | Stackprotectreq + | Nocapture + | Noredzone + | Noimplicitfloat + | Naked end module Icmp = struct diff -r a8c05e69647e import/llvm.org/llvm/bindings/ocaml/llvm/llvm.mli --- a/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.mli Fri Dec 25 17:35:09 2009 -0800 +++ b/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.mli Sun Dec 27 11:38:15 200...

...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 k...

..., !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 assig...

Hello, David > Ah, ok. I think I know what I have to do. I'll put callseq_start/end nodes > around the TLS addressing. Don't do that (tm) I'm testing the fix. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

...I'm guessing that's the critical difference. Is there a reason that route was taken in TOT? Why have an SDNode represent a bunch of instructions rather than just "properly" creating them? > >> I'm testing the fix. > > > > Ok, I'll try to "mark noredzone" thing and see if that works. > > It does, I verified this with the testcase you attached to PR. The > problem is not stack allocation, but red zone thing. Well, we shouldn't be using the redzone because any function that uses TLS is not a leaf (at least on X86). Simply marking...

...anguage 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 groups wit...

...mber 2009 12:30, Anton Korobeynikov wrote: > Hello, David > > > Ah, ok. I think I know what I have to do. I'll put callseq_start/end > > nodes around the TLS addressing. > > Don't do that (tm) Why not? > I'm testing the fix. Ok, I'll try to "mark noredzone" thing and see if that works. -Dave

...call (mostly due to presence of post-RA scheduler). And technically this "bunch of instructions" is a whole, not something + call. > Well, we shouldn't be using the redzone because any function that uses > TLS is not a leaf (at least on X86).  Simply marking the function "noredzone" > seems like a bit of a hack to me.  How do we guarantee some other piece of > code that thinks the function is a leaf won't do something else to screw > things up? As I said, this is temporary workaround until I will commit a fix (just in the case if you're in hurry). --...

...+ | Common > + | Linker_private > end > > module Visibility = struct > @@ -79,6 +84,15 @@ > | Nest > | Readnone > | Readonly > + | Noinline > + | Alwaysinline > + | Optforsize > + | Stackprotect > + | Stackprotectreq > + | Nocapture > + | Noredzone > + | Noimplicitfloat > + | Naked > end > > module Icmp = struct > diff -r a8c05e69647e import/llvm.org/llvm/bindings/ocaml/llvm/llvm.mli > --- a/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.mli Fri Dec 25 17:35:09 2009 -0800 > +++ b/import/llvm.org/llvm/bindings/ocaml/...

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

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" }

...] https://reviews.llvm.org/D42759 '[CGP] Split large data structres to sink more GEPs' by Haicheng Wu [0.00%/25.00%] https://reviews.llvm.org/D45189 '[MachineOutliner][AArch64] Keep track of functions that use a red zone in AArch64MachineFunctionInfo and use that instead of checking for noredzone in the MachineOutliner' by Jessica Paquette [0.00%/25.00%] https://reviews.llvm.org/D46107 '[AArch64] Codegen for v8.2A dot product intrinsics' by Oliver Stannard [0.00%/12.50%] https://reviews.llvm.org/D45541 '[globalisel] Update GlobalISel emitter to match new representation of e...

On Nov 20, 2012, at 11:03 AM, Meador Inge <meadori at codesourcery.com> wrote: > On Nov 13, 2012, at 12:20 AM, Bill Wendling wrote: > >> IR Changes >> ---------- >> >> The attributes will be specified within the IR. This allows us to generate code >> that the user wants. This also has the advantage that it will no longer be >> necessary to specify

...Program arguments: /home/scratch/llvm/build/bin/opt -instnamer 1. Running pass 'Function Pass Manager' on module '<stdin>'. 2. Running pass 'Module Verifier' on function '@fw_csr_iterator_init' Aborted The bytecode of the function is: ; Function Attrs: noredzone nounwind define void @fw_csr_iterator_init(%struct.fw_csr_iterator* nocapture %ci, i32* %p) #1 { tail call void @llvm.dbg.value(metadata !{%struct.fw_csr_iterator* %ci}, i64 0, metadata !159), !dbg !3500 tail call void @llvm.dbg.value(metadata !{i32* %p}, i64 0, metadata !160), !dbg !3500 %1...

...n 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 values associ...

...vm.org/D42759 '[CGP] Split large data > structres to sink more GEPs' by Haicheng Wu > [0.00%/25.00%] https://reviews.llvm.org/D45189 '[MachineOutliner][AArch64] > Keep track of functions that use a red zone in AArch64MachineFunctionInfo > and use that instead of checking for noredzone in the MachineOutliner' by > Jessica Paquette > [0.00%/25.00%] https://reviews.llvm.org/D46107 '[AArch64] Codegen for v8.2A > dot product intrinsics' by Oliver Stannard > [0.00%/12.50%] https://reviews.llvm.org/D45541 '[globalisel] Update > GlobalISel emitter to matc...

...nd the Red Zone is not disabled, if we are a leaf // function, and use up to 128 bytes of stack space, don't have a frame // pointer, calls, or dynamic alloca then we do not need to adjust the // stack pointer (we fit in the Red Zone). if (Is64Bit && !Fn->hasFnAttr(Attribute::NoRedZone) && !needsStackRealignment(MF) && !MFI->hasVarSizedObjects() && // No dynamic alloca. !MFI->adjustsStack() && // No calls. !IsWin64) { // Win64 has no Red Zone uin...

Hi Marcelo, That should be fixed now at r184239. Sorry about the failure! -bw On Jun 17, 2013, at 6:16 AM, Marcelo Sousa <marceloabsousa at gmail.com> wrote: > Hello, > > I'm getting an error when running opt with what seems to be a valid bytecode file compiled from one the Linux Kernel files. > The error is: > opt: /home/scratch/llvm/lib/IR/Attributes.cpp:119: