search for: gvs

Hello llvm-dev@ I have a pass that puts a global constant data array into the module. And another pass that gets runned by lld during LTO stage. When I look at bytecode files corresponding to source TUs produced by `clang -flto`, I can see GVs inserted by my pass #1. However, when pass #2 gets to run, these GV's are gone. I figured out that passing -mllvm -compute-dead=0 to the linker fixes the problem, but I'm not sure if it is right thing to do. Ideally, I'd like to trick LTO to ignore only mine GVs during compute-dead ana...

I am getting a timeout on running totem .... searching led me to think its gvs related.... Error creating proxy: Error calling StartServiceByName for org.gtk.vfs.GoaVolumeMonitor: Timeout was reached (g-io-error-quark, 24) Then totem does start - but with like a 30 second delay. I ran this command and it says its inactive systemctl --user status gvfs-mtp-volume-monitor.serv...

Hi Tim, The global merge pass puts the GVs into a sturcture to guarantee their address are contiguous. It works for static GVs but for global hidden GVs, this will cause name resoltion fail during linking .o into .so Any thoughs? Thanks, Weiming > Hi Weiming, > > On 12 March 2014 17:43, Weiming Zhao <weimingz at codeaurora.o...

...m.dbg.declare(!1) } --- Here !1 and !2 encodes debug info for a local variable 'b' and global variable 'a' respectively. !1 is one of the llvm.dbg.declare argument so it is seen any LLVM IR walker. However, !2 is "invisible" here. The proposal is to introduce @llvm.dbg.gvs = ![ !2 ] where llvm.dbg.gvs provides an anchor for such floating metadata encoding global variables. One could encode type information using such floating metadata for optimizer's use. For example, %struct.mystruct = type { i32, i32 } @mm = common global %struct.mystruct zeroinitializer !1...

...re !1 and !2 encodes debug info for a local variable 'b' and global > variable 'a' respectively. !1 is one of the llvm.dbg.declare argument > so it is seen any LLVM IR walker. However, !2 is "invisible" here. > > The proposal is to introduce > > @llvm.dbg.gvs = ![ !2 ] I talked with Devang about this and we came up with this syntax: !llvm.dbg.gvs = { !2 } which is nicely analogous with the syntax for named vs. unnamed values, and with having NamedMetadata inherit directly from Value, rather than from GlobalValue, since the only thing it needs is a na...

Hi, When I’m compiling a code with –fvisibility=hidden –fPIC for ARM, I find that LLVM generates less optimized code than GCC. For example: test.cpp: void init(void *); int g0[100]; int g1[100]; int g2[100]; void foo() { init(&g0); init(&g1); init(&g2); } Clang will emit 1 GOT entry for each GV and 2 instructions to get the address: ldr

...Best Regards, Seva Gluschenko CTO @ http://webkontrol.ru (http://webkontrol.ru/) February 9, 2018 2:01 PM, "Karthik Subrahmanya" <ksubrahm at redhat.com (mailto:%22Karthik%20Subrahmanya%22%20<ksubrahm at redhat.com>)> wrote: On Fri, Feb 9, 2018 at 3:23 PM, Seva Gluschenko <gvs at webkontrol.ru (mailto:gvs at webkontrol.ru)> wrote: Hi Karthik, Thank you for your reply. The heal is still undergoing, as the /var/log/glusterfs/glustershd.log keeps growing, and there's a lot of pending entries in the heal info. The gluster version is 3.10.9 and 3.10.10 (the version u...

...ou are running2. gluster volume heal <volname> info summary or gluster volume heal <volname> info3. getfattr -d -e hex -m . <filepath-on-brick> output of any one of the which is pending heal from all the bricks Regards,Karthik On Thu, Feb 8, 2018 at 12:48 PM, Seva Gluschenko <gvs at webkontrol.ru (mailto:gvs at webkontrol.ru)> wrote: Hi folks, I'm troubled moving an arbiter brick to another server because of I/O load issues. My setup is as follows: # gluster volume info Volume Name: myvol Type: Distributed-Replicate Volume ID: 43ba517a-ac09-461e-99da-a197759a7dc8...

Hi folks, I'm troubled moving an arbiter brick to another server because of I/O load issues. My setup is as follows: # gluster volume info Volume Name: myvol Type: Distributed-Replicate Volume ID: 43ba517a-ac09-461e-99da-a197759a7dc8 Status: Started Snapshot Count: 0 Number of Bricks: 3 x (2 + 1) = 9 Transport-type: tcp Bricks: Brick1: gv0:/data/glusterfs Brick2: gv1:/data/glusterfs Brick3:

Hi Rafael, Yes, merging gv prevents linker to do garbage collection. Should it be implemented as a peephole pass? If we do it too early, the distance between GVs are not fixed yet. PS: Below is the GCC output with "extern" hidden: ldr r2, .L2 stmfd sp!, {r3, lr} .save {r3, lr} .LPIC0: add r0, pc, r2 bl _Z4initPv(PLT) ldr r1, .L2+4 .LPIC1: add r0, pc, r1 bl _Z4initPv(PLT) ldr r0, .L2+8 .LPIC2: add r0, pc, r0 ldmfd sp!, {r3, lr} b _Z4in...

..., etc.  Am I mis-remembering?  If not, what's the status > of that?  We'd like to switch over to a proper scheme if we can. Now, each MI has line number info. The work is in progress to put debug info into LLVM instructions. The first step is to move away from all those pesky llvm.dbg.* GVs and use metadata. - Devang

...F sense, so it’s silly to pretend that LLVM >> visibility is the same as ELF visibility. ELF protected visibility is basically >> the semantics LLVM already assigns to default visibility. > > Except that we still produce STV_DEFAULT. Basically we have a mode > where we handle GVs as if they were protected but produce a > STV_DEFAULT. Yes, I don’t think this is a justifiable position. We either do or do not support interposition of global definitions. > If we are going to drop it, I think the only workable default solution > would be for -fsemantic-interposition...

...In other words, I get: gvfs-mount smb://mydomain\;toralf.lund at theserver/myshare Password required for share myshare on theserver Password: Password required for share myshare on theserver Password: Password required for share myshare on theserver Password: [ I enter the correct password, but gvs-mount keeps asking... Behaviour is the same if I try to open the URL in the file manager instead. ] mount -t cifs -o user=toralf.lund,workgroup=mydomain //theserver/myshare /tmp_mnt/ Password: [ At this stage the filesystem is mounted, as long as I enter the correct password. ] Does anyone ha...

On Jul 27, 2009, at 10:10 AM, Devang Patel wrote: > In LLVM IR metadata is used to attach auxiliary information with > various IR constructs. Currently metadata information is represented > using MDNode and MDString. The metadata can refer to LLVM values but > these references are not counted as regular "uses" of these values > because metadata is maintained 'on the

...the default. But we need to do it gently. I'd prefer to complete the API to support both models and *then* consider making the change. We do not want to disrupt existing clients. 4. Most *real* implementation should use its down custom memory manager. The default manager (or malloc for GVs) works for lli. But that's a command line tool for testing, it isn't necessarily how things must be done. I am glad to see the push to design and implement a proper API to support both models. I intend to review the code later today. Sorry about the delay. Evan On Jul 1, 2009, at...

...> JITed, > which raises a question: shouldn't it generate the GV to some non- > executable > memory block?? My patch doesn't attempt to fix this last concern. There are two ways to go about this. Either we enhance memory manager interface to create non-executable memory for GVs etc. Or we keep the memory manager simple and let the JIT change the privilege as it sees fit. I prefer the later unless there is a good argument for an alternative. Evan > > > Thanks, > Nuno > > P.S.: the control flow of this bug is quite complex, so feel free to > a...

Hi all, First post to the list, I hope you can help or guide me on this task. I am involved in a project that requires to re-link extracted and edited IR code Thus I want to know if these tools can be used in this way? clang++-4.0 code03.cpp -emit-llvm -S -o code03.ll llvm-extract-4.0 code03.ll -func main -S -o extracted_main.ll llvm-link-4.0 code03.ll -only-needed -override extracted_main.ll

> We have been JITing kernels and having a memory manager for globals > would be a big win there (clean up a few hacks to make things go in > the correct locations). I'm also guessing that Dale's client at Apple is using a custom memory manager, since without doing that there's no way to get the size of the code block in order to send it over the wire. Adding an

> On Mar 11, 2016, at 11:26 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Now, there are a number of things about linkage that are kindof orthogonal, >> and it would be nice to model them more orthogonally. That would be a major >> change in representation, though. Absent the will to do that, I propose >> that we: >> - remove/deprecate

...are running 2. gluster volume heal <volname> info summary or gluster volume heal <volname> info 3. getfattr -d -e hex -m . <filepath-on-brick> output of any one of the which is pending heal from all the bricks Regards, Karthik On Thu, Feb 8, 2018 at 12:48 PM, Seva Gluschenko <gvs at webkontrol.ru> wrote: > Hi folks, > > I'm troubled moving an arbiter brick to another server because of I/O load > issues. My setup is as follows: > > # gluster volume info > > Volume Name: myvol > Type: Distributed-Replicate > Volume ID: 43ba517a-ac09-461e-...