Displaying 20 results from an estimated 1200 matches similar to: "[LLVMdev] Handling of undef in the IR"
2015 May 05
1
[LLVMdev] Naryreassociate vs reassociate
On Tue, May 5, 2015 at 10:20 AM, Jingyue Wu <jingyue at google.com> wrote:
> Hi Daniel,
>
> I presume you mean, instead of assigning function arguments distinct ranks
> (http://llvm.org/docs/doxygen/html/Reassociate_8cpp_source.html#l00282), we
> should group function arguments in favor of existing pairings.
Existing = pairings reassociate already chose before
*not*
existing
2010 Apr 22
0
[LLVMdev] 2.7 release notes
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) :
---
2015 Mar 13
3
[LLVMdev] Question about shouldMergeGEPs in InstructionCombining
On Fri, Mar 13, 2015 at 10:16 AM Mark Heffernan <meheff at google.com> wrote:
> On Thu, Mar 12, 2015 at 2:34 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
>> It is not clear to me at all that preventing the merging is the right
>> solution. There are a large number of analysis, including alias analysis,
>> and optimizations that use GetUnderlyingObject, and
2010 Apr 22
8
[LLVMdev] 2.7 release notes
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
2014 Jul 01
2
[LLVMdev] Probable error in InstCombine
I've found what appears to be a bug in instcombine. Specifically, the transformation of -(X/C) to X/(-C) is invalid if C == INT_MIN.
Specifically, if I have
> define i32 @foo(i32 %x) #0 {
> entry:
> %div = sdiv i32 %x, -2147483648
> %sub = sub nsw i32 0, %div
> ret i32 %sub
> }
then opt -instcombine will produce
> define i32 @foo(i32 %x) #0 {
> entry:
> %sub
2010 Apr 22
1
[LLVMdev] 2.7 release notes
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
2011 Nov 17
2
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
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
2011 Nov 16
0
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
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
2011 Nov 15
3
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
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
2011 Feb 04
3
[LLVMdev] ConstantBuilder proposal
Here's a sketch of what I am proposing for ConstantBuilder.
I'd like feedback on naming conventions, doc comments, etc.
//===-- llvm/Support/ConstantBuilder.h - Builder for Constants --*- C++
-*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
2018 May 08
4
more reassociation in IR
There are at least 3 active proposals to add reassociative optimizations in
IR:
[1] D41574 <https://reviews.llvm.org/D41574>- a new pass for
reassociation/factoring
[2] D46336 <https://reviews.llvm.org/D46336> - enhance -instcombine to do
more reassociation/factoring
[3] D45842 <https://reviews.llvm.org/D45842> - add to the existing
-reassociate pass to enable factoring
2015 Feb 02
2
[LLVMdev] Reassociate and Canonicalization of Expressions
Hi,
I encountered some bugs in Reassociate [1] where we are hitting some assertions:
assert(!Duplicates.count(Factor) &&
"Shouldn't have two constant factors, missed a canonicalize");
assert(NumAddedValues > 1 && "Each occurrence should contribute a value”);
My understanding is that these assertions enforce that when processing an
2018 May 10
2
more reassociation in IR
On Wed, May 9, 2018 at 10:39 AM, Hiroshi Yamauchi <yamauchi at google.com>
wrote:
>
>
> On Tue, May 8, 2018 at 11:15 AM Daniel Berlin <dberlin at dberlin.org> wrote:
>
>>
>>
>> On Tue, May 8, 2018 at 10:38 AM, Hiroshi Yamauchi via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> (
>>> I came across this issue in
2018 May 10
2
more reassociation in IR
On Thu, May 10, 2018 at 12:05 PM, Hiroshi Yamauchi <yamauchi at google.com>
wrote:
>
>
> On Wed, May 9, 2018 at 8:24 PM Daniel Berlin <dberlin at dberlin.org> wrote:
>
>>
>>
>> On Wed, May 9, 2018 at 10:39 AM, Hiroshi Yamauchi <yamauchi at google.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, May 8, 2018 at 11:15 AM
2018 May 08
2
more reassociation in IR
On Tue, May 8, 2018 at 10:38 AM, Hiroshi Yamauchi via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> (
> I came across this issue in the context of
> D46336 <https://reviews.llvm.org/D46336>.
>
> Thanks, Sanjay, for starting this discussion.)
>
> If
> we will
> move
> reassociation,
> or keep additional ones
> ,
> out of instcombine,
2018 May 08
0
more reassociation in IR
(
I came across this issue in the context of
D46336 <https://reviews.llvm.org/D46336>.
Thanks, Sanjay, for starting this discussion.)
If
we will
move
reassociation,
or keep additional ones
,
out of instcombine,
open questions for me would be
:
1. Since -reassociate isn't a fixed point pass, we might need to repeat
"-instcombine -reassociate" multiple times to
2018 May 09
4
more reassociation in IR
> On May 8, 2018, at 9:50 AM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> 1. The reassociate pass that exists right now was *originally* (AFAIK) written to enable CSE/GVN to do better.
Agreed. The original mindset included a (naive) belief that going with a canonical form was better than teaching redundancy elimination to handle abstractions (as a matter
2012 Nov 20
3
[LLVMdev] [cfe-dev] !!! 3.2 Release branch patching and the Code Owners
Duncan,
I would like to merge r168035, r168181 and r168291 as
one reassociate changeset:
Have you heard from Chris regarding r168291?
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/156364.html
Pawel
> On 20/11/12 05:57, Chris Lattner wrote:
>> Fwiw, I approve both of these patches if they are still unmerged.
> ...
>>>
2015 Feb 04
3
[LLVMdev] Reassociate and Canonicalization of Expressions
>> On Feb 2, 2015, at 11:12 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>>
>> Hi,
>>
>> I encountered some bugs in Reassociate [1] where we are hitting some
>> assertions:
>>
>> assert(!Duplicates.count(Factor) &&
>> "Shouldn't have two constant factors, missed a
>> canonicalize");
2018 May 10
0
more reassociation in IR
On Wed, May 9, 2018 at 8:24 PM Daniel Berlin <dberlin at dberlin.org> wrote:
>
>
> On Wed, May 9, 2018 at 10:39 AM, Hiroshi Yamauchi <yamauchi at google.com>
> wrote:
>
>>
>>
>> On Tue, May 8, 2018 at 11:15 AM Daniel Berlin <dberlin at dberlin.org>
>> wrote:
>>
>>>
>>>
>>> On Tue, May 8, 2018 at 10:38 AM,