search for: ptrcast

...he optimizer/ > codegen to perform more aggressive stack slot merging. It seems no more prone to abuse to reserve an address space for const memory. Within a const region, all pointers to the const data are in the const address space. So rather than starting with a intrinsic, you start with a ptrcast. This would also make checking trivial stores to const regions easy in the verifier. Andrew

FYI, I wrote up some thoughts on this here: http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt The intention is to allow front-ends to express things like "I know this memory is a constant in this region" and to allow the optimizer/ codegen to perform more aggressive stack slot merging. -Chris

...ace casts > for this purpose. But I feel that this problem is likely not specific > to PTX. A target that uses different pointer sizes for different > address spaces would be hit by this issue even more, since a bitcast > would not even be valid IR. I agree with this, probably a 'ptrcast' instruction would better fits the various cases allowing the targets to handle correctly all the cases where the size/value change. It seems that there are various 'little' problems in the way address spaces are currently handled. I think it may be useful to list the various issue...

...0x0873124d llvm::BitCastInst::BitCastInst(llvm::Value*, llvm::Type const*, llvm::Twine const&, llvm::Instruction*) + 65 I insert extra two instructions to a byte code, the corresponding code is quite simple: LoadInst* ptrVal = new LoadInst(ptr, "foobar", false, next); CastInst* ptrCast = new BitCastInst(ptrVal, charPtrType, "cast1", next); If I comment out the CastInst statement, it runs fine. Any hint what is wrong? Thanks, Neal -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/2010...

...x i32>* %masked_load202 = load <4 x i32>* %ptr_cast_for_load, align 4 %gather_bitcast = bitcast <4 x i32> %masked_load202 to <4 x float> %float2uint = fptoui <4 x float> %gather_bitcast to <4 x i8> %ptr190 = getelementptr [8 x i8]* %tmpcast, i64 0, i64 2 %ptrcast = bitcast i8* %ptr190 to <4 x i8>* store <4 x i8> %float2uint, <4 x i8>* %ptrcast, align 2 %ptr194 = getelementptr [8 x i8]* %tmpcast, i64 0, i64 1 %ptr_cast_for_load203 = bitcast i8* %ptr194 to <4 x i8>* %masked_load195204 = load <4 x i8>* %ptr_cast_for_load20...

...s you perform this sort of check outside of "bitcast" lowering. The more broad issue I see here is that we need changes to the IR to make sure the mid-level optimizers don't break your code; specifically, using "bitcast" for lossy conversions is unsafe (so you need a "ptrcast" operation which can perform potentially lossy conversions), and you need to update TargetData so we can correctly compute the size of an arbitrary pointer. I was under the impression that you were planning to propose a fix for those separately, but it doesn't look like you have. -Eli

...s purpose. But I feel that this problem is likely not specific >> to PTX. A target that uses different pointer sizes for different >> address spaces would be hit by this issue even more, since a bitcast >> would not even be valid IR. > > I agree with this, probably a 'ptrcast' instruction would better fits the various cases allowing the targets to handle correctly all the cases where the size/value change. > > It seems that there are various 'little' problems in the way address spaces are currently handled. I think it may be useful to list the various...

...urpose. But I feel that this problem is likely not specific > > to PTX. A target that uses different pointer sizes for different > > address spaces would be hit by this issue even more, since a bitcast > > would not even be valid IR. > > I agree with this, probably a 'ptrcast' instruction would better fits the various > cases allowing the targets to handle correctly all the cases where the > size/value change. > > It seems that there are various 'little' problems in the way address spaces are > currently handled. I think it may be useful to l...

> -----Original Message----- > From: Villmow, Micah > Sent: Friday, August 24, 2012 2:56 PM > To: 'Eli Friedman' > Cc: LLVM Developers Mailing List > Subject: RE: [LLVMdev] RFC: Supporting different sized address space > arithmetic > > Eli, > There is a patch that implements the beginning what I think is the > correct approach to support the backend

...hat this problem is likely not specific > >> to PTX. A target that uses different pointer sizes for different > >> address spaces would be hit by this issue even more, since a bitcast > >> would not even be valid IR. > > > > I agree with this, probably a 'ptrcast' instruction would better fits > the various cases allowing the targets to handle correctly all the cases > where the size/value change. > > > > It seems that there are various 'little' problems in the way address > spaces are currently handled. I think it may be us...

Greetings, I have a Zig implementation of ceil which is emitted into LLVM IR like this: ; Function Attrs: nobuiltin nounwind define internal fastcc float @ceil(float) unnamed_addr #3 !dbg !644 { Entry: %x = alloca float, align 4 store float %0, float* %x call void @llvm.dbg.declare(metadata float* %x, metadata !649, metadata !494), !dbg !651 %1 = load float, float* %x, !dbg !652 %2 =

Why should SelectionDAGBuilder generate an explicit bitcast for a no-op bitcast? By definition, no bits are changed; so if the EVTs match, there is nothing to do. The fundamental problem is how address spaces are handled, and specifically how they are converted, in LLVM IR. Address space casts are currently implemented with bitcasts (in general). While this works out for the LLVM IR type

...f check outside of "bitcast" lowering. > > > The more broad issue I see here is that we need changes to the IR to > make sure the mid-level optimizers don't break your code; specifically, > using "bitcast" for lossy conversions is unsafe (so you need a "ptrcast" > operation which can perform potentially lossy conversions), and you need > to update TargetData so we can correctly compute the size of an > arbitrary pointer. I was under the impression that you were planning to > propose a fix for those separately, but it doesn't look lik...

On 08/08/2013 11:04 AM, David Chisnall wrote: > What happens when I link together two IR modules from different front ends that have different language-specific address spaces? I agree with Micah: if during the linking two IR modules there are incoherences (e.g. in module1 2 -> 1 and in module2 2 -> 3) then the modules are incompatible and the link process should fail. > I would be

...u += m; } u &= ~m; @bitCast(f32, u) } else { forceEval(x + 0x1.0p120); if (u >> 31 != 0) { return -0.0; } else { 1.0 } } } pub fn forceEval(value: f32) { var x: f32 = undefined; const p = @ptrCast(&volatile f32, &x); *p = x; } export fn do_test() -> bool { return ceil(f32(0.0)) == ceil32(0.0); } ----------------------- With no optimizations, the do_test function returns true, which is expected. With -O3, the module gets rewritten to: > > -- > Mehdi >...

...forceEval(x + 0x1.0p120); >> if (u >> 31 != 0) { >> return -0.0; >> } else { >> 1.0 >> } >> } >> } >> pub fn forceEval(value: f32) { >> var x: f32 = undefined; >> const p = @ptrCast(&volatile f32, &x); >> *p = x; >> } >> >> >> export fn do_test() -> bool { >> return ceil(f32(0.0)) == ceil32(0.0); >> } >> >> >> ----------------------- >> >> With no optimizations, the do_test function retu...