search for: loc0

> call void @llvm.dbg.declare( { }* bitcast(i32* %loc0 to { }*), { }* bitcast (%llvm.dbg.variable.type* @llvm.dbg.variable1 to { }*) ) This is not legal. The distinction here is that the bitcast as an argument is a constant expression and requires constant arguments, and %loc0 is not constant. Introducing the temp variable is the "right way&qu...

I have been trying to compile some Llvm code that I generate, and I am running into a problem assembling my ll code. Here is a snippet of the code I am trying to compile: %loc0 = alloca i32 call void @llvm.dbg.declare( { }* bitcast(i32* %loc0 to { }*), { }* bitcast (%llvm.dbg.variable.type* @llvm.dbg.variable1 to { }*) ) I get an error from the second line of code: Invalid reference to global Just to try to get the code to compile, I replaced the reference t...

...q %v0, %v1 == Transformed to ==> %v0 = load GCREF, GCREF* %ptr_0 %v0.i = ptrtoint %v0 %v1 = load GCREF, GCREF* %ptr_0 %v1.i = ptrtoint %v1 %cmp = icmp eq %v0.i, %v1.i is also invalid. ## Round tripping GCREF's through Integers The following transform is invalid: %v0 = load GCREF, GCREF* %loc0 store GCREF %v0, GCREF* %loc1 == Transformed to ==> %v0 = load i64, i64* (bitcast %loc0) store i64 %v0, i64* (bitcast %loc1) because if "L" in the second version is between the load and the store, "G" will not include `%v0` even though we need to report it to the GC (otherwi...

...ep back, summarized the requirements, and approached this anew.  The real requirement we have is: A way to construct a managed pointer to a stack location (or any other unmanaged location) such that it is interoperable with other GC pointers. The way we do it currently is using addrspacecast: %loc0 = alloca i8 %1 = addrspacecast i8* %loc0 to i8 addrspace(1)* I'm wondering if: (a) There is a better way to do this to better suite managed-code analysis/transformation phases, and (b) If generating the managed-pointer by construction alloca addrspace(1)* is the way to do it. Thanks, Swaro...

I have been using shorewall and freeswan successfully for 3 or more years now. But they have all been using the Linux 2.4 kernel. My current configuration is (as the title suggests) using SuSE 9.1 which has a 2.6.5 kernel and freeswan 2.0.4 built-in. After much reading and a lot of trial and error, I did get this combination to work with Shorewall 2.0.9. It is happily talking to an older Mandrake

...t Mangling: Available Multi-port Match: Available Extended Multi-port Match: Not available Connection Tracking Match: Not available Packet Type Match: Available Policy Match: Not available Physdev Match: Not available IP range Match: Available Determining Zones... Zones: net loc0 loc1 wlan Validating interfaces file... Validating hosts file... Validating Policy file... Determining Hosts in Zones... Internet Zone: ppp0:0.0.0.0/0 eth0_net Zone: eth0:0.0.0.0/0 eth1_net Zone: eth1:0.0.0.0/0 wlan_net Zone: eth2:0.0.0.0/0 Processing /etc/shorewall/init ... Pre-process...

I''m seeing what may be sort of strange behavior - My machine is behind a Shorewall firewall, which, in the rules section, includes: AllowBitTorrent, any source, any dest I''m wondering - how is my machine behind the firewall able to upload, since no port forwarding related to bittorrent is taking place? (Just to clarify - it IS uploading) I looked at the AllowBitTorrent

...seen this happen organically (so this is likely hypothetical), but I want to prevent it from happening even if there is a reason to do it. >> ## Round tripping GCREF's through Integers >> >> The following transform is invalid: >> >> %v0 = load GCREF, GCREF* %loc0 >> store GCREF %v0, GCREF* %loc1 >> == Transformed to ==> >> %v0 = load i64, i64* (bitcast %loc0) >> store i64 %v0, i64* (bitcast %loc1) >> >> because if "L" in the second version is between the load and the >> store, "G" will...

...e below patch to kernel source. >+diff --git a/arch/ia64/kernel/pal.S b/arch/ia64/kernel/pal.S >+index 0b53344..f02b0f7 100644 >+--- a/arch/ia64/kernel/pal.S >++++ b/arch/ia64/kernel/pal.S >+@@ -84,7 +84,8 @@ GLOBAL_ENTRY(ia64_pal_call_static) >+ mov ar.pfs = loc1 >+ mov rp = loc0 >+ ;; >+- srlz.d // seralize restoration of psr.l >++ srlz.i // seralize restoration of psr.l seralize ---> serialize Best Regards, Akio Takebe

Hi. I rewrote the patch according to the comments. I adopted generating in-place code because it looks the quickest way. The point Eddie wanted to discuss is how to generate code and its ABI. i.e. in-place generating v.s. direct jump v.s. indirect function call Indirect function call doesn't make sense because ivt.S is compiled multi times. And it is up to pv instances to choose in-place

Hi. I rewrote the patch according to the comments. I adopted generating in-place code because it looks the quickest way. The point Eddie wanted to discuss is how to generate code and its ABI. i.e. in-place generating v.s. direct jump v.s. indirect function call Indirect function call doesn't make sense because ivt.S is compiled multi times. And it is up to pv instances to choose in-place

Currently, the alloca instruction always allocates in the generic address space (0). This proposal is to extend the semantics of alloca instruction to allow allocation in any specified address space. Proposed Syntax <result> = alloca [inalloca] <type> [, <ty> <NumElements>] [, align <alignment>] [, addrspace <num>] ; yields type addrspace(num)*:result

Hi. The patch I send before was too large so that it was dropped from the maling list. I'm sending again with smaller size. This patch set is the xen paravirtualization of hand written assenbly code. And I expect that much clean up is necessary before merge. We really need the feed back before starting actual clean up as Eddie already said before. Eddie discussed how to clean up and suggested

Hi. The patch I send before was too large so that it was dropped from the maling list. I'm sending again with smaller size. This patch set is the xen paravirtualization of hand written assenbly code. And I expect that much clean up is necessary before merge. We really need the feed back before starting actual clean up as Eddie already said before. Eddie discussed how to clean up and suggested

Hi. This patchset implements xen/ia64 domU support. Qing He and Eddie Dong also has been woring on pv_ops so that I want to discuss before going further and avoid duplicated work. I suppose that Eddie will also post his own patch. So reviewing both patches, we can reach to better pv_ops interface. - I didn't changed the ia64 intrinsic paravirtulization abi from the last post. Presumably it

Hi. This patchset implements xen/ia64 domU support. Qing He and Eddie Dong also has been woring on pv_ops so that I want to discuss before going further and avoid duplicated work. I suppose that Eddie will also post his own patch. So reviewing both patches, we can reach to better pv_ops interface. - I didn't changed the ia64 intrinsic paravirtulization abi from the last post. Presumably it

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Now all the comments so far have been addressed, but only a few exceptions. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops.

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Now all the comments so far have been addressed, but only a few exceptions. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops.

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Please review and comments. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops. Currently only ia64/xen pv_ops implementation

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Please review and comments. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops. Currently only ia64/xen pv_ops implementation