similar to: [LLVMdev] RFE: Rename LLVM_ATTRIBUTE_{READONLY, READNONE} to LLVM_{READONLY, READNONE}

What's the reason for renaming them? -bw On Mar 8, 2012, at 4:57 PM, Daniel Dunbar wrote: > Hi all, > > I would like to rename > LLVM_ATTRIBUTE_READONLY to LLVM_READONLY > and > LLVM_ATTRIBUTE_READNONE to LLVM_READNONE > > Any objections? > > - Daniel > _______________________________________________ > LLVM Developers mailing list > LLVMdev at

On Mar 8, 2012, at 6:31 PM, Bill Wendling wrote: > What's the reason for renaming them? I can think of two things: 1) it being an attribute is an implementation detail 2) it being long makes it annoying to use :) -Chris > > -bw > > On Mar 8, 2012, at 4:57 PM, Daniel Dunbar wrote: > >> Hi all, >> >> I would like to rename >>

On Thu, Mar 8, 2012 at 7:03 PM, Chris Lattner <clattner at apple.com> wrote: > > On Mar 8, 2012, at 6:31 PM, Bill Wendling wrote: > >> What's the reason for renaming them? > > I can think of two things: > > 1) it being an attribute is an implementation detail > 2) it being long makes it annoying to use :) Exactly. - Daniel > -Chris > >>

On 6/21/12 2:23 AM, Duncan Sands wrote: > Hi John, > >> Are functions marked as readnone or readonly in the LLVM IR allowed to >> generate output or to exhibit exceptional behavior (e.g., calling >> abort(), generating an MMU fault, etc.)? > they are allowed to unwind exceptions for example, since in theory this > can occur without scrunching externally visible memory

Hi John, > Are functions marked as readnone or readonly in the LLVM IR allowed to > generate output or to exhibit exceptional behavior (e.g., calling > abort(), generating an MMU fault, etc.)? they are allowed to unwind exceptions for example, since in theory this can occur without scrunching externally visible memory (for example unwinding can be done by having functions return an

Dear All, Are functions marked as readnone or readonly in the LLVM IR allowed to generate output or to exhibit exceptional behavior (e.g., calling abort(), generating an MMU fault, etc.)? The SAFECode compiler has a set of run-time checks that pass or fail based solely on the input arguments and, in some cases, global state. They do not modify a program's global state, but they do print

On 01/05/2017 01:20 PM, Sanjoy Das wrote: > Hi Hal, > > On Thu, Jan 5, 2017 at 11:10 AM, Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> It is still only a function of its arguments, so it can be CSE'd. > That's a good example -- we can CSE it without worrying about the > memory state flowing in. > > In fact, if we have: > > *a =

Hi Michael, On Mon, Jan 2, 2017 at 11:49 PM, Michael Kuperstein <michael.kuperstein at gmail.com> wrote: > This sounds right to me. > > IIUC, historically, readonly and readnone are meant to model the "pure" and > "const" GCC attributes. These attributes make pretty strong guarantees: > > "[a pure] function can be subject to common subexpression

On 01/05/2017 12:45 PM, Mehdi Amini wrote: > >> On Jan 5, 2017, at 10:39 AM, Hal Finkel via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> On 01/05/2017 12:17 PM, Reid Kleckner wrote: >>> On Thu, Jan 5, 2017 at 9:19 AM, Hal Finkel via llvm-dev >>> <llvm-dev at lists.llvm.org

On 01/05/2017 03:10 PM, Reid Kleckner wrote: > On Thu, Jan 5, 2017 at 10:39 AM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > I don't understand why that's desirable, and I think it would > severely limit our ability to infer these attributes for functions > that unwind. You'd need to prove things -- likely

On Tue, Jan 3, 2017 at 10:47 AM, Michael Kuperstein via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Tue, Jan 3, 2017 at 9:59 AM, Sanjoy Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Michael, >> >> On Mon, Jan 2, 2017 at 11:49 PM, Michael Kuperstein >> <michael.kuperstein at gmail.com> wrote: >> > This

On 01/05/2017 10:55 AM, Sanjoy Das wrote: > Hi Hal, > > On Thu, Jan 5, 2017 at 6:12 AM, Hal Finkel <hfinkel at anl.gov> wrote: >> On 01/04/2017 10:35 PM, Sanjoy Das via llvm-dev wrote: >>> I just realized that there's an annoying corner case to this scheme -- >>> I can't DSE stores across readnone maythrow function calls because the >>>

On 01/04/2017 10:35 PM, Sanjoy Das via llvm-dev wrote: > I just realized that there's an annoying corner case to this scheme -- > I can't DSE stores across readnone maythrow function calls because the > exception handler could read memory. That is, in: > > try { > *a = 10; > call void @readnone_mayunwind_fn(); > *a = 20; > } catch (...) { >

On 01/05/2017 12:17 PM, Reid Kleckner wrote: > On Thu, Jan 5, 2017 at 9:19 AM, Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > On 01/05/2017 10:55 AM, Sanjoy Das wrote: > > Hi Hal, > > On Thu, Jan 5, 2017 at 6:12 AM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel

LLVM today does not clearly specify if a function specified to not write to memory (i.e. readonly or readnone) is allowed to throw exceptions. LangRef is ambiguous on this issue. The normative statement is "[readnone/readonly functions] cannot unwind exceptions by calling the C++ exception throwing methods" which does not decide an answer for non C++ languages. It used to say (h/t

Could we expose predicates defined in the target InstrInfo.td file to the MachineVerifier? We use BuildMI() to create many instructions after ISEL, but the predicates are not being checked at this point. Thus, I could forget to check the target and build an instruction that is illegal for a specific configuration. In such a case it would be nice if the MachineVerifier could detect this for me.

Hi, I am writing a plugin to get information about the OpenMP constructs from the AST. I am basically writing a “RecursiveASTVisitor” and I am trying to find the OpenMP statement and get information like filename and line of code. When I am visiting recursively each statement I have my own switch on the “StmtClass” and for now I am focusing on “OMPParallelForDirectiveClass”. In my understanding,

On Oct 5, 2009, at 7:21 AM, Stephan Reiter wrote: > Hi all, > > I'm currently building a DSL for a computer graphics project that is > not unlike NVIDIA's Cg. I have an intrinsic with the following > signature > > float4 sample(texture tex, float2 coords); > > that is translated to this LLVM IR code: > > declare void @"sample"(%float4* noalias

Hi Stephan, >> In order to perform this transform the optimizers would have to work out >> that sample does not modify any global state. This cannot be done without >> knowing the definition of sample, but you only provide a declaration. > > Which is why I am trying to supply this additional information in a > custom alias analysis pass, but it doesn't seem to

Hi! if I have a function with readnone attribute. is it then allowed to access an "internal constant" which is defined outside the function in llvm ir assembly? -Jochen