Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] [HEADS UP] Upcoming API change (create --> Create)"
2008 May 16
0
[LLVMdev] API CHANGE: create*() --> Create
Hi all,
I have checked in the API change for the classes
BinaryOperator, CmpInst and CastInst, that upper-
cases all methods that begin with "create".
As announced (<http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-May/
014636.html>)
the legacy API is still in place. If you observe something to the
contrary, please alert me and I shall fix it.
Please note that LLVM 2.3 will have
2010 Feb 07
0
[LLVMdev] Help with Mac OS X 10.6.2 build
Hi,
Try these scripts to build llvm and llvm-gcc. It's the ones I use and I
managed to get them to work when I saw another build script using those
CFLAGS.
They compile llvm and stuff using only x86_64, but you can then generate
code for i386 (just use a different backend). The configuration options
are at the top of the scripts and they install llvm and llvm-gcc to ~/llvm.
Regards,
2010 Feb 07
3
[LLVMdev] Help with Mac OS X 10.6.2 build
Greetings,
I am having trouble getting the Kaleidoscope example to build from
tutorial #3 on Mac OS X 10.6.2. I didn't have too much trouble
getting llvm-2.6 and llvm-gcc-frontend to build. Thanks for the help.
Here are the steps I followed:
Environment variables for build
export LLVMOBJDIR=/opt/llvm
export TARGETOPTIONS='--with-arch=nocona --with-tune=generic'
export
2012 Jul 31
3
[LLVMdev] rotate
Andy,
Here is the left circular shift operator patch. I apologize to the reviewer
in advance. The patch has a good bit of fine detail. Any
comments/criticisms?
Some caveats...
1) This is just the bare minimum needed to make the left circular shift
operator work (e.g. no instruction combining).
2) I tried my best to select operator names in the existing style; please
feel free to change them as
2008 Jun 17
0
[LLVMdev] Transforming ConstantExprs to Instructions
On Tue, Jun 17, 2008 at 8:50 AM, Matthijs Kooijman <matthijs at stdin.nl> wrote:
> Hi,
>
> I've been struggling with constantexprs for a bit. I'm working on a pass that
> transforms global variables to local variables, and in particular the
> GetElementPtrConstantExpr is a bit troublesome. For my transformation to
> properly work, a global value should only be used
2018 Feb 07
0
retpoline mitigation and 6.0
On Wed, 2018-02-07 at 06:20 +0000, Chandler Carruth wrote:
> I've landed the patch in r324449.
>
> Before we merge this into two different Clang release branches and
> almost immediately release one of them, I would really like someone
> to confirm that this patch works well with the Linux kernel. David,
> if you're up for that, it would be great. Alternatively, Guenter
2019 May 10
2
[Pipeliner] MachinePipeliner TargetInstrInfo hooks need more information?
Hello,
I'm working on integrating the MachinePipeliner.cpp pass into our VLIW
backend, and so far we've managed to get it working with some nice
speedups.
Unlike Hexagon however, our backend doesn't generate hardware loop
instructions and so all our loops are a combination of induction
variables, comparisons and branches. So when it came to implementing
reduceLoopCount for our
2016 Jul 21
2
Remove zext-unfolding from InstCombine
Hi all,
I have a question regarding a transformation that is carried out in InstCombine, which has been introduced by r48715. It unfolds expressions of the form `zext(or(icmp, (icmp)))` to `or(zext(icmp), zext(icmp)))` to expose pairs of `zext(icmp)`. In a subsequent iteration these `zext(icmp)` pairs could then (possibly) be optimized by another optimization (which has already been there before
2011 Jan 24
3
[LLVMdev] How to change the type of an Instruction?
Hi,
Nick, thanks for the reply.
I still have a problem: I only need to "clone" an Instruction, changing its
type. That is, I would like to keep all characteristics of the old
Instruction and create a new one only with a different type. I am trying
create a new Instruction thus:
%3 = add nsw i32 %1, %2 ; <i16> [#uses=2] //Old Instruction
Value* Op0 = I->getOperand(0);
Value*
2008 May 22
0
[LLVMdev] Latest SVN head (gcc front end) build failed
Did you update llvm and build that first?
-Tanya
On May 21, 2008, at 10:29 PM, Rajika Kumarasiri wrote:
> hi all,
> I was trying to build the latest LLVM gcc front end and it failed.
>
> rajika@:~/project/llvm/dst-directory$ svn info | grep URL
> URL: http://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk
>
> configure option: ../dst-directory/configure --prefix=/usr/local/
2008 May 22
2
[LLVMdev] Latest SVN head (gcc front end) build failed
hi all,
I was trying to build the latest LLVM gcc front end and it failed.
rajika@:~/project/llvm/dst-directory$ svn info | grep URL
URL: http://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk
configure option: ../dst-directory/configure --prefix=/usr/local/
--enable-llvm=/home/rajika/project/llvm/llvm-objects
it gave me the following errors
../../dst-directory/gcc/llvm-convert.cpp:1163: error:
2013 Jan 16
0
[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments
On Wed, Jan 16, 2013 at 12:53:55AM +0100, Joerg Sonnenberger wrote:
> Let's come back to this. The attached patch decouples InstSimplify from
> the alias analysis and provides the conservative logic for when pointers
> are not equal.
Let's take the version with the cleanup from IRC. *sigh* Dealing with
too many copies.
Joerg
-------------- next part --------------
Index:
2010 Jun 12
1
[LLVMdev] Memory leak?
Hi folk,
I get the following stack trace and do have any clue how to fix the problem.
0 opt 0x087ecc99
1 opt 0x087ed265
2 0xb7f6a400 __kernel_sigreturn + 0
3 opt 0x086d4198
llvm::LeakDetector::addGarbageObject(llvm::Value const*) + 29
4 opt 0x0872945f llvm::Instruction::Instruction(llvm::Type
const*, unsigned int,
2016 Jul 27
2
Remove zext-unfolding from InstCombine
Hi Sanjay,
thank you a lot for your answer. I understand that in your examples it is desirable that `foo` and `goo` are canonicalized to the same IR, i.e., something like `@goo`. However, I still have a few open questions, but please correct me in case I'm thinking in the wrong direction.
> Am 21.07.2016 um 18:51 schrieb Sanjay Patel <spatel at rotateright.com>:
>
> I've
2016 Aug 04
2
Remove zext-unfolding from InstCombine
Hi Sanjay,
> Am 02.08.2016 um 21:39 schrieb Sanjay Patel <spatel at rotateright.com>:
>
> Hi Matthias -
>
> Sorry for the delayed reply. I think you're on the right path with D22864.
No problem, thank you for your answer!
> If I'm understanding it correctly, my foo() example and zext_or_icmp_icmp() will be equivalent after your patch is added to InstCombine.
2010 May 16
1
[LLVMdev] How to access the return value of a CallInst
Hi all:
I am trying to get the return value of a call instruction that I
inserted during the optimization pass I wrote. I have something like
the following:
CallInst *InitCall = CallInst::Create(InitFn, Args.begin(), Args.end(),
"log_load_addr_ret", LI);
CastInst *InsertedCast =
2013 Jan 15
2
[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments
On Wed, Dec 12, 2012 at 01:59:55PM -0800, Dan Gohman wrote:
> The bug here isn't in clang's use of noalias or in BasicAliasAnalysis'
> implementation of noalias; it's in the code that's optimizing the
> icmp.
Let's come back to this. The attached patch decouples InstSimplify from
the alias analysis and provides the conservative logic for when pointers
are not
2017 Nov 17
4
Signed or unsigned EQ/NEQ
Hello,
In one of the loop transformations I am developing, I need to convert eq
and neq loop latch condition into less than or greater than depending on
the control flow.
The problem is that CmpInst::ICMP_EQ and CmpInst::ICMP_NE are neither
signed nor unsigned in LLVM. Also, I did not find a way to find out if the
integer operands of the CmpInst are signed or unsigned. Apparently, LLVM
does
2007 Jan 19
2
[LLVMdev] Vector comparisons
Are the ICMP and FCMP instructions meant to accept vectors operands
or no? Verifier excludes vectors, as does the AsmParser[1]. But the
CmpInst constructor accepts vectors[2], and they are documented as
allowed:
> If the operands [of icmp or fcmp] are packed typed, the elements of
> the vector are compared in turn and the predicate must hold for all
> elements.
— Gordon
[1]
2008 Jul 01
0
[LLVMdev] vmkit on x86_64
Hi Zsombor,
Thanks for the patch! Unfortunately I can't apply it because the llvm
API has moved from BinaryOperator::create to BinaryOperator::Create. Are
you using svn head?
Now on the x86_64 part. There has been very little work on porting vmkit
on x86_64. If you're having compilation problems, I suppose it's in the
garbage collector directory (GCMmap2). If you could make the