similar to: [LLVMdev] Missing optimization - constant parameter

> I expected that this optimization would be picked > up in a cse, gvn, machine-cse or even peepholing pass. > > Comments? At the LLVM IR level this is represented as define i64 @caller() #0 { entry: store i64* @val, i64** @p, align 8, !tbaa !0 store i64 12345123400, i64* @val, align 8, !tbaa !3 %call = tail call i64 @xtr(i64 12345123400) #2 ret i64 %call } Which is

On Aug 2, 2013, at 1:37 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> I expected that this optimization would be picked >> up in a cse, gvn, machine-cse or even peepholing pass. >> >> Comments? > > > At the LLVM IR level this is represented as > > define i64 @caller() #0 { > entry: > store i64* @val, i64** @p, align 8, !tbaa

Are you sure that's it? I commented that block out, rebuilt llvm 3.3, and it still duplicates the constant. My concern is that long constant loads increase code size and if they can be avoided by better targeting it would be a win. My project's application of llvm tends to use a lot of long constants so this can be a significant optimization. I'll do some more debugging now that you

Hi, I'm having some trouble wirting an instruction in the X86 backend. I made a new intrinsic and I wrote a custom inserter for my intrinsic in the X86 backend. Everything works fine, except for one instruction that I can't find how to write. I want to add this instruction in one of my machine basic block: mov [rdi], 0 How can I achieve that with the LLVM api? I tried several

Hi, Thx for your help... Here is the IR code: ; ModuleID = 'foo_bar.c' target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" @.str = private unnamed_addr constant [6 x i8] c"MAIN\0A\00", align 1 ; Function Attrs: nounwind uwtable define i32 @main(i32 %argc, i8** %argv) #0 { entry: %retval = alloca i32,

Hi, I'm having trouble using virtual register in the X86 backend. I implemented a new intrinsic and I use a custom inserter. The goal of the intrinsic is to set the content of the stack to zero at the end of each function. Here is my code: MachineBasicBlock * X86TargetLowering::EmitBURNSTACKWithCustomInserter( MachineInstr *MI, MachineBasicBlock

On Oct 10, 2013, at 7:59 AM, Maurice Marks <maurice.marks at gmail.com> wrote: > I went back to this problem after looking at some other things. Turning on debugging I noticed that the register coalescer is trying to do the "right thing" and merge vreg0 (the previous load of the constant) with the first parameter of the call (%rdi), which is exactly what gcc does in this case -

On Aug 5, 2013, at 8:34 AM, Maurice Marks <maurice.marks at gmail.com> wrote: > Are you sure that's it? I commented that block out, rebuilt llvm 3.3, and it still duplicates the constant. > My concern is that long constant loads increase code size and if they can be avoided by better targeting it would be a win. My project's application of llvm tends to use a lot of long

I went back to this problem after looking at some other things. Turning on debugging I noticed that the register coalescer is trying to do the "right thing" and merge vreg0 (the previous load of the constant) with the first parameter of the call (%rdi), which is exactly what gcc does in this case - eliminating a second constant load, but its refusing to do the merge: Here's the

Hi ! I'm trying to modify the code in a machine function pass… I added a new basicblock and I want to add a jump to an another BB from my new BB. Here is my code : bool Obfuscation::runOnMachineFunction(MachineFunction &MF) { MachineBasicBlock *newEntry = MF.CreateMachineBasicBlock(); MF.insert(MF.begin(), newEntry); std::vector<MachineBasicBlock*> origBB;

On Tue, 18 Dec 2018 at 07:11, Gleb Popov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > However, I haven't managed to get a "Constant<>" in the DAG when compiling for X86. I'm interested in how it is lowered. Can you please give me some guidance on this? How are you looking? When I run "llc -mtriple=x86_64-linux-gnu -debug-only=isel" on your IR I get

Hi, I'm still having problems implementing my custom inserter in the X86 backend. I found a solution to my last problem (http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/078296.html), by using a virtual register. The binary works when it's compiled in -O0, but not in -O1,-O2,... I really can't figure what I'm doing wrong... Any idea? Here is the code of my custom

Hello. I am in a habit of compiling daily snapshots of R-devel and R-patched on my Windows XP workstation. I have cygwin environment with up-to-date RTools and MiKTeX. I run cygwin and MiKTeX upadaters pretty often (every couple of days) so both of them are reasonably current. Recently I noticed a small annoyance when compiling R-dvel. It started happening right after I updated to the new

We have received an email in Ubuntu alerting us that something strange was going on during the r-base 2.7.1 rc build (see [1]). It seems that there is an error during the convertion of R-FAQ.texi to pdf. The following excerpt, taken from [2], shows the problem: /bin/sh: line 0: test: too many arguments TEXINPUTS=".:$TEXINPUTS" /usr/bin/texi2dvi --texinfo="@set UseExternalXrefs

This shouldn't have parsed. movq (%gs), %r14 That's trying to use%gs as a base register which isn't valid. GNU assembler rejects it. And coincidentally llvm-mc started rejecting it on trunk late last week. That's probably why it printed as %ebp. I don't know if there is an instruction to read the base of %gs directly. Maybe rdgsbase, but that's only available on Ivy

I am working on a project where we are integrating an existing pre-RA scheduler into LLVM and we are trying to match our peak register pressure values with the machine instruction schedulers values while using X86. I am finding some mismatches in test cases like the one attached. The registers "AH" and "AL" are live-out but not live-in and I don't see that they are defined

Full_Name: Martin O'Gorman Version: OS: Submission from: (NULL) (84.176.63.149) I have been looking at the PPC package and have a question. As the input data is comma separated, shouldn?t the command to read in the raw (no batch) mass spec data indicate that sep=?,? (marked below) ? Otherwise, the data read in is the pair of values (m/z,intensity). It is not obvious why that should be.

The size suffix thing is a weird quirk in our assembler I should look into fixing. Instructions in at&t syntax usually have a size suffix that is often optional For example: add %ax, %bx and addw %ax, %bx Are equivalent because the register name indicates the size. but for an instruction like this addw $1, (%ax) There is nothing to infer the size from so an explicit suffix is

Hi Everybody, i again have the problem in using tune.knn(), its giving an error saying missing values are not allowed.... again here is the script for BreastCancer Data, library(e1071) library(mda) trdata<-data.frame(train,row.names=NULL) attach(trdata) xtr <- subset(trdata, select = -Class) ytr <- Class bestpara <-tune.knn(xtr,ytr, k = 1:25, tunecontrol = tune.control(sampling

Dear all, I was wondering if you could help me with the following. I want to do calculate this equation: Ps(t)= (?_(r=1)^N Xtr* 1/?drs)/(?_(r=1)^N 1/?drs) Ps(t) ? Probability that taxon t will occur at site s (300 sites s) N ? Number of sites = from 1 to 49 Xtr ? Value for taxon t at site r (I have this information in a table, 40 taxa (columns) t, 49 sites r) drs ? Distance from site r to