Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] Instruction->mayReadFromMemory"
2006 May 12
0
[LLVMdev] Instruction->mayReadFromMemory
On Fri, 12 May 2006, Silken Tiger wrote:
> To find the first instructions which are not depending on others results. So
> far it seems to be working but i am missing instructions like:
> %tmp.1 = seteq int %argc, 2 ; <bool> [#uses=1]
> There seems only an function like llvm::Instruction::mayWriteToMemory
> but nothing like llvm::Instruction::mayReadFromMemory or
2006 May 12
1
[LLVMdev] Instruction->mayReadFromMemory
Hi Chris and list
Thanks for your quick answer :-).
Am Freitag, 12. Mai 2006 19:09 schrieb Chris Lattner:
> On Fri, 12 May 2006, Silken Tiger wrote:
> > To find the first instructions which are not depending on others results.
> > So far it seems to be working but i am missing instructions like:
> > %tmp.1 = seteq int %argc, 2 ; <bool> [#uses=1]
> >
2007 Mar 23
1
[LLVMdev] strange pass behaviour
Hi
I have written a pass which creates some scheduling information. Its called MParSchedule.
This pass works with opt. But when feeding it my experimental backend it seems to loose
instructions and fails to work. I am loading this stuff as .so libraries under linux and i am
using the amd64 version with a self compiled llvm-gcc.
With this call it works:
opt
2012 Feb 03
1
[LLVMdev] Issues with the llvm.stackrestore intrinsic - now LoopRotation handling of alloca
2012/2/3 Patrik Hägglund <patrik.h.hagglund at ericsson.com>:
> Hi,
>
> I've tracked the first problem (mentioned in my previous email, quoted
> below) down further, ending up in the handling of alloca in
> LoopRotation.cpp (from trunk):
>
> // If the instruction's operands are invariant and it doesn't read
> or write
> // memory, then it is
2006 May 30
3
[LLVMdev] Adding an object to llc (analysis pass)
Hi
> One would expect this, its a facility of the C++ language. The anonymous
> namespace is, essentially, the same as declaring everything in it
> static. That is, the symbols are not exported and not available for
> linking.
Yes, it was pretty clear after finding out that this isn't a linking error
which i suspected...
> > So for all those trying to add an analysis path:
2012 Feb 01
3
[LLVMdev] Issues with the llvm.stackrestore intrinsic
Hi,
I have two problems regarding the llvm.stackrestore intrinsic. I'm
running on 3.0, but a quick test on trunk also showed the same behavior.
First problem:
---------------
I have code like:
tmp1 = call llvm.stacksave()
tmp2 = alloca
[do some stuff with tmp2]
call llvm.stackrestore(tmp1)
[some other stuff]
tmp3 = call llvm.stacksave()
tmp4 = alloca
[do some stuff
2012 Feb 03
0
[LLVMdev] Issues with the llvm.stackrestore intrinsic - now LoopRotation handling of alloca
Hi,
I've tracked the first problem (mentioned in my previous email, quoted
below) down further, ending up in the handling of alloca in
LoopRotation.cpp (from trunk):
// If the instruction's operands are invariant and it doesn't read
or write
// memory, then it is safe to hoist. Doing this doesn't change the
order of
// execution in the preheader, but does
2011 Jul 05
1
[LLVMdev] Instructions that access memory @ the IR level
Hello,
I'm working with a pass that operates at the LLVM IR level. I need to run
some statistics on instructions that access memory, and I'm wondering, at
the IR level, which instructions aside from Load and Store access memory
directly as a result of their operation? I know on an ISA level, this
varies from arch to arch, but I'm wondering how LLVM has this set up at the
IR level.
2005 Jul 29
0
[LLVMdev] patch for pointer-to-array conversion
The enlosed patch for IndVarSimplify.cpp works even when the pointer
increment is deeply nested wrt pointer initialization, but note that it
needs to have loop structures preserved, as in the following:
int A[3000000], B[20000], C[100], Z;
volatile int I, J, K;
int main()
{
int i, j, k, *a, *b, *c;
for ( a = &A[0], i = 0; i != 300; i++ )
{
I++;
2006 Jun 01
2
[LLVMdev] Adding an object to llc (analysis pass)
Hi
> Right it does. However, does something *else* require MParSchedule? If
> so, what?
Ok, i am writing on a different backend based on the cbackend.
The test usage of this pass looks like this:
void getAnalysisUsage(AnalysisUsage &AU) const {
AU.addRequired<LoopInfo>();
AU.addRequired<MParSchedule>();
AU.setPreservesAll();
}
and then in the
2005 Jul 28
2
[LLVMdev] help with pointer-to-array conversion
I now understand that IndVarSimplify.cpp is capable of reproducing array
references when the pointer initialization from the array address is found
inside the immediately enclosing loop, such that in the following code:
int A[20000], B[100], Z;
int main()
{
int i, j, *a, *b;
for ( a = &A[0], i = 0; i != 200; i++ )
for ( b = &B[0], j = 0; j != 100; j++
2005 Jul 28
0
[LLVMdev] help with pointer-to-array conversion
On Thu, 28 Jul 2005, Naftali Schwartz wrote:
> I now understand that IndVarSimplify.cpp is capable of reproducing array
> references when the pointer initialization from the array address is found
> inside the immediately enclosing loop, such that in the following code:
Ok.
> int A[20000], B[100], Z;
> int main()
> {
> int i, j, *a, *b;
> for ( a =
2011 Aug 31
0
[LLVMdev] [PATCH] Split init.trampoline into init.trampoline & adjust.trampoline
Hi Sanjoy, the first and last patches look good (except that you didn't add any
tests for the auto-upgrade functionality). Comments on the other two below.
> Attached patches split init.trampoline into adjust.trampoline and
> init.trampoline, like in gcc.
>
> As mentioned in the previous mail, I've not made a documentation
> patch, since I'm not sure about what the
2010 May 05
2
[LLVMdev] How to cast an integer array to an integer pointer? (user question)
I am new to LLVM and couldn't find any llvm-user list, so I am posting
my user question here, sorry.
I am trying to create a simple "puts" call accepting the static string,
with the code below.
The last line (CallInst::Create) fails with an assert: "Calling a
function with a bad signature!"
Because the type of function is void(u8*) and the argument supplied is:
2008 Apr 29
0
[LLVMdev] [PATCH] use-diet for review
On Apr 29, 2008, at 1:27 AM, Gabor Greif wrote:
> Hi all,
>
> I have reported more than enough about the space savings achieved
> and the associated costs, here comes the current patch for review.
>
> Since this one is substantially smaller than the previous one, I did
> not cut it in pieces. The front part is about headers and the rest
> the .cpp and other files.
Hi
2006 May 31
2
[LLVMdev] Adding an object to llc (analysis pass)
Hi
Am Dienstag, 30. Mai 2006 19:21 schrieb Chris Lattner:
> On Tue, 30 May 2006, Silken Tiger wrote:
> > Everthing now compiles fine, but when running llc with invoking my own
> > backend derived from the cbackend i get the following error:
> > namespace llvm {
> > class MParSchedule : public BasicBlockPass {
> > public:
> >
> >
2019 Apr 10
2
getelementptr inbounds with offset 0
Hi,
>>> I see. Is there a quick answer to the questions why you need inbounds
>>> GEPs in that case? Can't you just use non-inbounds GEPs if you know you
>>> might not have a valid base ptr and "optimize" it to inbounds once that
>>> is proven?
>>
>> You mean on the Rust side? We emit GEPi for field accesses and array indexing.
2020 Jul 16
2
BitcodeReader.cpp bug under LTO
Hi guys,
We have found a bug of BitcodeReader.cpp in processing an LTO bitcode file. As LLVM doesn't emit use-list for LTO bitcode files, many forward references will happen when BitcodeReader processes the bitcode file, and LLVM uses placeholders for those forward references and resolve them later.
When parseConstants() reads in a CST_CODE_CE_SELECT record, e.g.
select
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
2006 May 09
1
[LLVMdev] Memory leaks in LLVM
Hi,
Probably some of the leaks Valgrind reports are spurious, but the numbers
seem to be significant enough to demand some attention:
==10132== LEAK SUMMARY:
==10132== definitely lost: 15,624 bytes in 558 blocks.
==10132== indirectly lost: 44,548 bytes in 1,591 blocks.
==10132== possibly lost: 37,576 bytes in 98 blocks.
==10132== still reachable: 1,336,876 bytes in 1,364 blocks.