similar to: [LLVMdev] Docs question: legality of inspecting other functions in a function pass

On 3 Jul 2013, at 23:05, Stephen Lin <swlin at post.harvard.edu> wrote: > Does anyone know if there's a defined policy about this, either way? > If so, I think it ought to be noted in the docs, for consistency. The prohibition exists, at least in part, because in theory it would be nice to be able to run passes in parallel. It's not a real limitation at the moment because

On Thu, Jul 4, 2013 at 1:45 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 3 Jul 2013, at 23:05, Stephen Lin <swlin at post.harvard.edu> wrote: > >> Does anyone know if there's a defined policy about this, either way? >> If so, I think it ought to be noted in the docs, for consistency. > > The prohibition exists, at least in part, because in

Hi Stephen, On 04/07/13 20:21, Stephen Lin wrote: > On Thu, Jul 4, 2013 at 1:45 AM, David Chisnall > <David.Chisnall at cl.cam.ac.uk> wrote: >> On 3 Jul 2013, at 23:05, Stephen Lin <swlin at post.harvard.edu> wrote: >> >>> Does anyone know if there's a defined policy about this, either way? >>> If so, I think it ought to be noted in the docs,

> both dragonegg and clang (AFAIK) run some function passes on each function > in turn as they are turned into LLVM IR. If such a function pass tried to > inspect other functions then they won't be able to see all function bodies > because they haven't all been output yet. And which functions do have > bodies > available to be inspected depends on the order in which

Hi Stephen, On 05/07/13 17:14, Stephen Lin wrote: >> both dragonegg and clang (AFAIK) run some function passes on each function >> in turn as they are turned into LLVM IR. If such a function pass tried to >> inspect other functions then they won't be able to see all function bodies >> because they haven't all been output yet. And which functions do have >>

Hi, I would like to add a new directive to FileCheck called CHECK-FOO (where FOO is a name under discussion right now) which is used to improve error messages. The idea is that you would use CHECK-FOO on any line that contains a unique identifier (typically labels, function definitions, etc.) that is guaranteed to only occur once in the file; FileCheck will then conceptually break the break the

> This is not true. The mathematically correct result for sqrt might not be a representable value in floating point, so rounding may occur between the two steps. In that case, pow2(sqrt(x)) != x. > > --Owen I think what Christoph is saying is that x will always be at least as accurate as pow2(sqrt(x)), so it's only unsafe in so far as one's code is actually depending on an

On Apr 23, 2013, at 7:15 PM, Stephen Lin <swlin at post.harvard.edu> wrote: >> This is not true. The mathematically correct result for sqrt might not be a representable value in floating point, so rounding may occur between the two steps. In that case, pow2(sqrt(x)) != x. > > I think what Christoph is saying is that x will always be at least as > accurate as pow2(sqrt(x)),

Oh, well, I don't actually have any objection to the patch (I'm not sure if Oscar does) or work in this direction. (So apologies for hijacking, it's just I wanted to back up the sentiment that Oscar expressed initially.) I'm honestly just trying to understand why the engineering focus is where it is, and wonders if anyone has put any thought into supporting our own (or possibly

Hello, To any out-of-tree targets, please be aware that I intend to commit a patch that will break the build of any target implementing TargetLoweringBase::isFMAFasterThanMulAndAdd, for the reasons described below. (Basically, the current interface definition is broken and not followed, and no in-tree target was doing the right thing with it, so it is unlikely any out-of-tree target is either...)

On 22 November 2013 19:11, Stephen Lin <swlin at post.harvard.edu> wrote: > Nadav and Arnold, > > What is the current status of vectorization pragmas? Do you think that's > something I might be able to take on if you two are busy with other things? > Hi Stephen, I was planing on having a look at that this month, but if you have the bandwidth for it, I won't impose.

Hi Rafael, I think you saw my other e-mail, but just in case you haven't, do you have any thoughts about making this an option that could be easily disabled on the command line without maintaing a patch to lit? I think it would help out-of-tree target maintainers to transition, since I'm sure there will be a lot of similarly broken tests to fix. Stephen On Thu, Jul 4, 2013 at 8:56 PM,

> I just bought an 11" mac air for when I'm travelling or somewhere else that > is not at work and wanted to be able to do llvm work on it. > > I got the the 8 gig version but with a 128 gig flash drive because it seemed > to be enough but if I had to create another partition for llvm, then maybe I > should get the 256 gig version. > > It's not really a work

Nadav and Arnold, What is the current status of vectorization pragmas? Do you think that's something I might be able to take on if you two are busy with other things? Stephen On Thu, Nov 14, 2013 at 11:10 AM, Nadav Rotem <nrotem at apple.com> wrote: > Its a good point. We will need to document the semantics of the > vectorization pragma well. > > On Nov 14, 2013, at

On 07/18/2013 04:39 PM, Eli Friedman wrote: > On Thu, Jul 18, 2013 at 4:29 PM, reed kotler <rkotler at mips.com> wrote: >> I built llvm and clang on my home mac which has just a normal mac os file >> system and everything seem to build just fine. >> >> Are there any requirements for needing linux style upper/lowercase file >> systems for llvm/clang tool

Its a good point. We will need to document the semantics of the vectorization pragma well. On Nov 14, 2013, at 10:58 AM, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi Nadav, > > On 14/11/13 17:38, Nadav Rotem wrote: >> Sure. Vectorization of stores is done by loading the current value from memory, blending the new value and saving it back to memory. > > Just a

Hi, Apologies if this has been proposed before; I couldn't find anything in basic searching. I've been writing tests lately and noticed that the error messages are not very helpful in cases where a check is incorrect but matches something that occurs in a later block: the checker continues assuming that the matched line is correct (no matter how much farther ahead it occurs) and then

On Jul 31, 2013 10:16 AM, "Stephen Lin" <swlin at post.harvard.edu> wrote: > > Oh, well, I don't actually have any objection to the patch (I'm not > sure if Oscar does) or work in this direction. (So apologies for > hijacking, it's just I wanted to back up the sentiment that Oscar > expressed initially.) > > I'm honestly just trying to

Hi, I noticed that ConstantFP::get automatically returns the appropriately types Constant depending on the LLVM type passed in (i.e. if called with a vector, it returns a splat vector with the given constant). Is there any simple way to do the inverse of this function? i.e., given a llvm::Value, check whether it is either a scalar of the given constant value or a splat vector with the given

We currently don't use pipefail when running test under make check. This has the undesirable property that it is really easy for tests to bitrot. For example, something like llc %s | FileCheck %s will still pass if llc crashes after printing what FileCheck was looking for. It is also easy to break the tests when refactoring. I have fixed tests that were doing %clang_cc1 -a-driver-options