search for: _a_la_

...g to undefined behavior, as > you note. That that point all bets are off. Divide by zero certainly > is a perfectly valid expression of undefined behavior. If we had a > delayed check we would have to put it somewhere before the udiv. We > would probably need some kind of fixup path _a_la_ IA64's check > instruction. The original code was well-behaved for all inputs. The final code has undefined behavior for some inputs. Fixup paths don't really seem to fit here. We're never going to want fixup paths in the final output, for example. And there is no way to fix up und...

...ehavior, as >> you note. That that point all bets are off. Divide by zero certainly >> is a perfectly valid expression of undefined behavior. If we had a >> delayed check we would have to put it somewhere before the udiv. We >> would probably need some kind of fixup path _a_la_ IA64's check >> instruction. > > The original code was well-behaved for all inputs. > The final code has undefined behavior for some inputs. > > Fixup paths don't really seem to fit here. We're never going > to want fixup paths in the final output, for example. A...

...was violated, leading to undefined behavior, as you note. That that point all bets are off. Divide by zero certainly is a perfectly valid expression of undefined behavior. If we had a delayed check we would have to put it somewhere before the udiv. We would probably need some kind of fixup path _a_la_ IA64's check instruction. The whole point of this is to be able to hoist nsw operations. But any form of static speculation will require fixup code in the cases where the speculation is wrong. There really is a cost to hoisting code with potential side-efffects across branches. I don't...

...this operation. 3. Merge the ValueMaps from the Module clone and all the pristine function ValueMaps so that if V->V' in the Module map and V->V'' in the pristine function map, make V''->V' in the Module map. 4. Fix up arguments to the pristine functions _a_la_ what is done in CloneModule. 5. Delete the function bodies of all functions in the cloned Module (these are the optimized bodies) by calling deleteBody on them. 6. Call CloneFunctionInto to clone the pristine functions into the cloned Module. 7. Fix up linkages (set function linkages...

...t; We already support most of the PTX instruction set. Texture lookup, > structs&arrays, function calls, vector types, different address spaces > and many intrinsics. Do you generate masked operations? If so, are you managing masks/predicates with your own target-specific representation _a_la_ the current ARM backend? >> If they are unrelated, can you do a comparison of the two? Perhaps >> there are holes in each that can be filled by the other. It would be >> a shame to have two completely different PTX backends. >> > I don't know much about the targ...

On Wednesday 09 July 2008 13:24, Devang Patel wrote: > Is it possible to explain intended use of original unoptimized version ? bugpoint. I want to run it on the IR produced by our frontend. This will help us generate new LLVM tests we can send upstream. We've fixed bugs that aren't caught by the upstream tests and it would be nice to capture the problem and make the test

...lease split it into reasonable sized chunks and get them reviewed. > > -Chris > Are there any volunteers out there? :) Thanks! David A. Greene wrote: > > Do you generate masked operations? If so, are you managing > masks/predicates with your own target-specific representation _a_la_ the > current ARM backend? > No, currently not. I only insert perdicates for the conditional branch implementation. But I don't think they are that important. A divergent branch(inside one warp) is more or less the same. Still it would be nice to have them and investicate the integr...

The recent discussion of nsw led me to go back and review the current definition of nsw in greater depth, and it turns out that even with all the theoretical effort, it's still logically inconsistent. First, a warning: The scenario below is artificial. This is just a demonstration. Also, ignore the fact that instcombine would zap everything. Depending on that would be an implicit pass

On Wed, 15 Aug 2007, David A. Greene wrote: >>> and thus won't be real useful for Windows. >> >> Why not just use the unlocked stdio calls? > > Because I'm lazy. :) It seems much easier to use a robust and well tested system than invent a new crazy scheme ;-) > No, seriously, because I just haven't had time to do it. And because I'm > lazy.

On Aug 10, 2010, at 12:05 PM, David A. Greene wrote: >> >> The PTXBackend probably needs more test cases. I'm currently covering a >> lot of LLVM and PTX features but the test suite is still not exhaustive. >> I took the coding standards into account and the license is now >> compatible to LLVM. I don't know what else needs to be done? > > Checking

...he ValueMaps from the Module clone and all the pristine > function > ValueMaps so that if V->V' in the Module map and V->V'' in the > pristine > function map, make V''->V' in the Module map. > > 4. Fix up arguments to the pristine functions _a_la_ what is done in > CloneModule. > > 5. Delete the function bodies of all functions in the cloned Module > (these are > the optimized bodies) by calling deleteBody on them. > > 6. Call CloneFunctionInto to clone the pristine functions into the > cloned > Module. &...

...the PTX instruction set. Texture lookup, > > structs&arrays, function calls, vector types, different address > spaces > > and many intrinsics. > > Do you generate masked operations? If so, are you managing > masks/predicates with your own target-specific representation _a_la_ > the > current ARM backend? > > >> If they are unrelated, can you do a comparison of the two? Perhaps > >> there are holes in each that can be filled by the other. It would > be > >> a shame to have two completely different PTX backends. > >> >...

Hi! >>> Hi there, >>> >>> I have a working prototype of PTX backend, and I would like to >>> upstream it if possible. This backend is implemented by LLVM's target >>> independent code generator framework; I think this will make it easier >>> to maintain. >>> >> How does this relate, at all, to the backend here:

I agree that a single vector index is sufficient for many cases. Matt Pharr (from the ISPC compiler), showed me an interesting case where there is a single pointer into an array. In this case we need to have two indices, where the first index is zero. Once the basic patch is in, we can start looking at adding support for arrays and multiple indices. Nadav -----Original Message----- From: David

Hi David, Thanks for asking. On Mon, Aug 9, 2010 at 3:25 PM, David A. Greene <greened at obbligato.org> wrote: > Che-Liang Chiou <clchiou at gmail.com> writes: > >> Hi there, >> >> I have a working prototype of PTX backend, and I would like to >> upstream it if possible.  This backend is implemented by LLVM's target >> independent code