search for: castable

...)* @g to i32 (i64)*)(i64 %a) ret i32 %call } > > The idea of improving the inliner is also great, but you may find that > it's needed for cases other than this one if i'm right about the > instcombine. > Sadly, the combine fails because InstCombine queries CastInst::isBitCastable to determine the castable-ness of the parameter type and the argument type. It isn't bitcastable though, it's ptrtoint/inttoptr castable. The following patch opens up the optimization: --- a/lib/Transforms/InstCombine/InstCombineCalls.cpp +++ b/lib/Transforms/InstCombine/InstCombineCalls....

...thing to do with the standard R connections). The class has a slot, called id, which is essentially a void* pointer to a C++ stream object. Up until now I worked on 32-bit machines and the id slot was an integer, so one could cast back and forth between int and void*. However, on 64-bits void* is castable to 'long int', but not int, which poses a couple of problems: a) since there is no R arrays of 'long int' type what other built-in type can I use to store void*. For example double is big enough to accommodate void*, but I am not sure whether casting will work both ways. b) assuming...

...ining. Or at least spell out somewhere exactly what the rules are on addrspacecast, which seems to be what's missing at the moment - is it something that can be used to describe a form of addressable memory, or is it formally required that they share the same byte size and that if an address is castable from one addrspace to another, that those values are strict aliases of one another.

...DF data variable > layer.dim.name, # name of the datavar dimension indexing the layers (e.g., 'time') > sigdigs=3, # precision to use for stats > brick, # ... for data (a RasterBrick) > map.list, # maps to overlay on data: list of SpatialLines or objects castable thereto > pdf.fp, # path to PDF output > pdf.height, > pdf.width > ) { > nonplot.vis.layers(nc.fp, datavar.name, layer.dim.name, sigdigs) > plot.vis.layers(brick, map.list, pdf.fp, pdf.height, pdf.width) > } # end visualize.layers ... > plot.vis.layers...

On Thu, Apr 18, 2013 at 11:11 PM, John Criswell <criswell at illinois.edu>wrote: > On 4/18/13 9:56 AM, Jun Koi wrote: > > hi, > > i am writing a simple LLVM pass to analyze the Store instruction. > my pass derives from InstVisitor class, and the method to handle Store > instruction is like this: > > void MyPass::visitStoreInst(StoreInst &I) { > ... >

Philip, I post here because I think AlwaysInliner should inline it. I want to detect the indirect calls for Inliner, and I want to hear inputs. let me define indirect call first in my idea. In one single expression, one function may be subject to bitcast more than one time. we can detect this situation and treat it as a regular call of last function, is that okay? thanks, --lx On Mon, Jan 5,

The following combine(-enabling transformation) makes me uncomfortable:   gep(addrspacecast(gep p0) to p1)   addrspacecast(gep(gep p0)) to p1 It's applied at visitAddrSpaceCast in InstCombineCasts.cpp. Before this, I'd always assumed address spaces were very much "user domain". Datalayout even supports marking a space as "non-integral", to designate that manipulation as

Hi, I'm part of an engineering team doing research on persistent memory support and we have stumbled upon an interesting problem. The issue is, we would like to be able to use the standard library containers in a persistent memory context (think NVDIMM-N). What I mean is that you allocate a container from said memory, use it like you normally would. After the application terminates, expectedly

Hi Nick, I have committed 0001 as r203788. I'm working on fixes for 0002 - 0014. > After reading through this patch series, I feel like I'm missing > something important. Where's the sort function? It looks like we're > still comparing all functions to all other functions. When you insert functions into std::set or its analogs it does all the job for you. Since