search for: overindex

...ease elaborate on > >> this? > > > > Nevermind ;) -- I changed my mind, the safety issue is with > > non-aligned loads that might cross page boundaries. Is that right? > > That's just one safety issue. There are others. Can you be more specific? You mentioned overindexing in your other e-mail, exactly what do you mean by that? Thanks again, Hal > > > If so, I think this proposal is good (although obviously the docs > > need > > to make clear what the faulting behavior of these intrinsics is). > > The behavior should be not to ever f...

Hi, With kernel 2.4.10, when I do $ mkdir foo; cd foo; rmdir ../foo; ls then ls becomes zombie. $ ps xau|grep ls liu 596 0.0 0.0 148 88 ? D 12:03 0:00 ls This does not happen with 2.4.10 on an ext2 filesystem, nor with 2.4.9/ext3. The command cd instead of ls is OK. Distribution is Slackware 8.0 and the kernels are stock ones. Liu

On Sep 9, 2010, at 1:48 PM, David Greene wrote: > LLVM 2.7's ScalarEvolution.cpp has this scary comment: > > // It's tempting to handle inttoptr and ptrtoint as no-ops, however this can > // lead to pointer expressions which cannot safely be expanded to GEPs, > // because ScalarEvolution doesn't respect the GEP aliasing rules when > // simplifying integer

LLVM 2.7's ScalarEvolution.cpp has this scary comment: // It's tempting to handle inttoptr and ptrtoint as no-ops, however this can // lead to pointer expressions which cannot safely be expanded to GEPs, // because ScalarEvolution doesn't respect the GEP aliasing rules when // simplifying integer expressions. I think I understand what the comment is saying. If a GEP has

Hi Dan, Thanks for reply, it seems that Dan Gohman wrote: > On Jul 23, 2009, at 1:59 AM, Mark Shannon wrote: > >> Hi Dan, >> >> What you are proposing is a major change in the semantics of llvm. >> >> You are taking certain uses of an instruction that have well defined >> behaviour and undefining them. >> >> Have you made any estimate of how

----- Original Message ----- > From: "Hal Finkel" <hfinkel at anl.gov> > To: "Elena Demikhovsky" <elena.demikhovsky at intel.com> > Cc: dag at cray.com, llvmdev at cs.uiuc.edu > Sent: Friday, October 24, 2014 8:39:56 AM > Subject: Re: [LLVMdev] Adding masked vector load and store intrinsics > > ----- Original Message ----- > > From:

Dear All, As of late I am having a hard time getting my head around how array accesses are translated by Clang into LLVM IR: the often misunderstood GEP instruction. I am trying to reverse-engineer array accesses to discover the number of dimensions and actual indexes of the original, and I am beginning to wonder whether this is possible at all. To illustrate (some of) my troubles, consider

On Jul 23, 2009, at 1:59 AM, Mark Shannon wrote: > Hi Dan, > > What you are proposing is a major change in the semantics of llvm. > > You are taking certain uses of an instruction that have well defined > behaviour and undefining them. > > Have you made any estimate of how many peoples' code this may or may > not > break? > > I think this is a *very* bad

> For the loads, I'm must less sure. Why can't we represent the loads as select(mask, load(addr), passthru)? It is true, that the load might get separated from the select so that isel might not see it (because isel if basic-block local), but we can add some code in CodeGenPrep to fix that for targets on which it is useful to do so (which is a more-general solution than the intrinsic