search for: isfporfpvectorti

Chris Lattner <clattner at apple.com> writes: > Ok, the LLVM 2.7 release notes are in near final shape. Please take > a look and suggest improvements (or, better yet, just commit > improvements if you have commit access): About the API changes, some that hit me when I ported some code to LLVM 2.7, and not in the release notes (I had sent a private email some time ago) : ---

Hi all, I have a very simple test case (thanks to bugpoint) that hit an assert in reassociate. (the assert is (C->getType()->isIntOrIntVectorTy() && "Cannot NEG a nonintegral value!"), function getNeg) The function is taking a Constant as argument, but the assert does not expect an undef. I’m not sure whose responsibility is it to handle that (caller?). Do we have to

Ok, the LLVM 2.7 release notes are in near final shape. Please take a look and suggest improvements (or, better yet, just commit improvements if you have commit access): http://llvm.org/docs/ReleaseNotes.html Things still needed are marked with FIXMEs. These include: 1. Clang needs a blurb describing what's new in 2.7. Have the clang folks been doing anything for the last 6 months? 2. I

Thanks, I must have missed these, added. On Apr 22, 2010, at 1:28 AM, Matthieu Moy wrote: > Chris Lattner <clattner at apple.com> writes: > >> Ok, the LLVM 2.7 release notes are in near final shape. Please take >> a look and suggest improvements (or, better yet, just commit >> improvements if you have commit access): > > About the API changes, some that hit

On 11/17/2011 12:38 AM, Hal Finkel wrote: > Tobias, et al., > > Attached is the my autovectorization pass. Very nice. Will you be at the developer summit? Maybe we could discuss the integration there? Here a first review of the source code. > diff --git a/docs/Passes.html b/docs/Passes.html > index 5c42f3f..076effa 100644 > --- a/docs/Passes.html > +++ b/docs/Passes.html

Tobias, I've attached an updated patch. It contains a few bug fixes and many (refactoring and coding-convention) changes inspired by your comments. I'm currently trying to fix the bug responsible for causing a compile failure when compiling test-suite/MultiSource/Applications/obsequi/toggle_move.c; after the pass begins to fuse instructions in a basic block in this file, the aliasing

Tobias, et al., Attached is the my autovectorization pass. I've fixed a bug that appears when using -bb-vectorize-aligned-only, fixed some 80-col violations, etc., and at least on x86_64, all test cases pass except for a few; and all of these failures look like instruction-selection bugs. For example: MultiSource/Applications/ClamAV - fails to compile shared_sha256.c with an error: error in

Tobias, I've attached the latest version of my autovectorization patch. I was able to add support for using the ScalarEvolution analysis for load/store pairing (thanks for your help!). This led to a modest performance increase and a modest compile-time increase. This version also has a cutoff as you suggested (although the default value is set high (4000 instructions between pairs) because

On 11/23/2011 05:52 PM, Hal Finkel wrote: > On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: >> > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: >>> > > Tobias, >>> > > >>> > > I've attached an updated patch. It contains a few bug fixes and many >>> > > (refactoring and coding-convention) changes inspired

Tobias, I've attached an updated copy of the patch. I believe that I accounted for all of your suggestions except for: 1. You said that I could make AA a member of the class and initialize it for each basic block. I suppose that I'd need to make it a pointer, but more generally, what is the thread-safely model that I should have in mind for the analysis passes (will multiple threads

On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > > Tobias, > > > > I've attached an updated patch. It contains a few bug fixes and many > > (refactoring and coding-convention) changes inspired by your comments. > > > > I'm currently trying to fix the bug responsible for causing a compile

On Fri, 2011-12-02 at 17:07 +0100, Tobias Grosser wrote: > On 11/23/2011 05:52 PM, Hal Finkel wrote: > > On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: > >> > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > >>> > > Tobias, > >>> > > > >>> > > I've attached an updated patch. It contains a few bug fixes

On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > Tobias, > > I've attached an updated patch. It contains a few bug fixes and many > (refactoring and coding-convention) changes inspired by your comments. > > I'm currently trying to fix the bug responsible for causing a compile > failure when compiling >