search for: semacheck

...arison between two vectors is supposed to result in the a 'signed' integer vector result. 'char' is always troublesome, though in C++ it is a discrete type. I made the following change in my copy (clang-3.3) that I think is a correct and valid change: File: tools/clang/lib/Sema/SemaChecking.cpp Function: Sema::GetSignedVectorType() Replace the fragment: if (TypeSize == Context.getTypeSize(Context.CharTy)) return Context.getExtVectorType(Context.CharTy, VTy->getNumElements()); ^^^^^^ with: if (TypeSize == Context.getTypeSize(Cont...

...of them. My bet is that the vast vast vast majority of them > will be small (and I’d guess a HUGE number of them have a distance of > +1/-1, whose query can be resolved without computing a numbering in the > first place). > > Can you do that experiment and report back, e.g. on the SemaChecking.cpp > testcase? > Fair enough. I made a patch to do that, and uploaded it here: https://reviews.llvm.org/D52510 I put it into a spreadsheet and made a histogram here: https://goo.gl/AMLBt7 I grouped the typical query distances into natural log buckets, and the table is small enough to pas...

> On Sep 24, 2018, at 10:19 AM, Reid Kleckner <rnk at google.com> wrote: > > To echo what Hal said, yes, it's a major change, but I think the improved complexity guarantees, simplicity, and elimination of certain classes of bugs is worth it. > > I think we have consensus that we should go forward with this. Would anyone mind formally stamping it in phab? So far everyone

...supposed to result in the a 'signed' integer vector result. > > 'char' is always troublesome, though in C++ it is a discrete type. I made > the following change in my copy (clang-3.3) that I think is a correct and > valid change: > > File: tools/clang/lib/Sema/SemaChecking.cpp > Function: Sema::GetSignedVectorType() > > Replace the fragment: > > if (TypeSize == Context.getTypeSize(Context.CharTy)) > return Context.getExtVectorType(Context.CharTy, > VTy->getNumElements()); > ^^^^^^ > wi...

...You'd add a declaration to include/llvm/IR/IntrinsicsXYZ.td (where XYZ is your target), and then you can select them with a normal pattern in your target's .td files. On the Clang side you'd add it to include/clang/Basic/BuiltinsXYZ.def and lib/CodeGen/CGBuiltin.cpp. Possibly lib/Sema/SemaChecking.cpp too if it has strange validity requirements. > 2.) Does the IR language have some kind of template support? > I'm not sure if this even possible - but I thought about having a template > function and when jitting the IR it could instantiate that template with the > now known...

Hello everyone, I have some questions about the possibilities with the LLVM but I'm not sure where to gather the information. 1.) Can I teach the LLVM new platform depended intrinsics? Like I provide assembly code and want to create a custom intrinsic for it. 2.) Does the IR language have some kind of template support? I'm not sure if this even possible - but I thought about having a

...arison between two vectors is supposed to result in the a 'signed' integer vector result. 'char' is always troublesome, though in C++ it is a discrete type. I made the following change in my copy (clang-3.3) that I think is a correct and valid change: File: tools/clang/lib/Sema/SemaChecking.cpp Function: Sema::GetSignedVectorType() Replace the fragment: if (TypeSize == Context.getTypeSize(Context.CharTy)) return Context.getExtVectorType(Context.CharTy, VTy->getNumElements()); ^^^^^^ with: if (TypeSize == Context.getTypeSize(Cont...

Hello, I was implementing the llvm_any_type in my intrinsic def int_csa_xxx : Intrinsic<[llvm_any_ty], [llvm_i32_ty]>; as the following in its corresponding builtins in Builtins.def: BUILTIN(__builtin_xxx, "v.", "nt") the "t" was sufficient here to not perform any type checking. The type checking was handled in CGBuiltin.cpp. This was working until

> On Feb 5, 2019, at 6:55 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > There is something similar going on in clang in SemaChecking.cpp. The difference is that each target can write its own verification code, which may check things like value ranges, for example. > The scheme you're proposing would invent a new attribute (a widespread change) that only implements partial checks (i.e. "is argument immediate or not...

Hi, I would like to solve the longstanding need for a way to indicate which parameters to an intrinsic are required to be immediates. It should be possible to declare in tablegen which parameters must be a trivial constant, or else the IR is invalid. The verifier could then reject invalid intrinsic calls, so code handling the intrinsics doesn’t need to worry about invalid arguments. Currently

L.S., I'm currently in the process of creating Debian packages for clang/llvm release 3.9.0. For this I'm using the steps as explained on 'http://apt.llvm.org/building-pkgs.php'. Up until now I have done: $ debcheckout svn://anonscm.debian.org/svn/pkg-llvm/llvm-toolchain/ $ cd llvm-toolchain/branches $ sh 3.9/debian/orig-tar.sh RELEASE_390 final Now, as is explained, I would