search for: undecorated

...uctions. >> >> Currently, we decorate instructions that initialize and copy >> aggregates with !tbaa.struct tags that generally cannot be >> transformed to !tbaa tags. For this reason every time we >> scalarize an aggregate, we leave resulting loads and stores >> undecorated, meaning optimization of such instructions cannot >> benefit from TBAA. > > I understand that we'd like to improve TBAA in a number of different > ways, and that probably involves replacing !tbaa.struct with an > enhanced !tbaa representation, but I don't understand the...

...rate accesses to slices with tags of their aggregates. That requires aggregate accesses to be described the same way we describe scalar accesses. To provide some background on importance of this matter, SROA and passing flattened parameters/returning values in clang together produce 75% of all undecorated loads and 90% if all undecorated stores on the LLVM code base under -O1. On 31/10/17 10:44, Ivan Kosarev wrote: > In short, the problem with !tbaa.struct is that in most cases it > cannot be converted to !tbaa. For transformations like SROA this means > they cannot propagate !tbaa.str...

On 4/4/2014 3:46 AM, David Chisnall wrote: > On 3 Apr 2014, at 20:49, Shankar Easwaran <shankare at codeaurora.org> wrote: > >> b) I am not planning to write a demangler. I was planning on using abi::__cxx_demangle if there was one available and the first character in the symbol was a _. >> If MSVC was defined, we would use the Undecorate API. > The demangler that

This is release 0.9.54 of Wine, a free implementation of Windows on Unix. What's new in this release: - Photoshop CS/CS2 should now work, please help us testing it. See http://wiki.winehq.org/AdobePhotoshop for details. - A number of RPC fixes. - Various improvements to the debugger support. - Lots of bug fixes. Because of lags created by using mirrors, this message may reach you

...ble runtime possibilities. The motivation for this is that optimizers that ignore metadata should always be safe. With !fpmath, theoretically there are ways this can fail. It also has the problem that there's nothing preventing a pass like GVN from merging a !fpmath-decorated operation with an undecorated operation, and nothing requiring it to strip the !fpmath tag when it does so. (This is a general problem with LLVM metadata semantics.) The current definition of !fpmath does not appear to require operations to return the same result each time they are evaluated. This fits with the way the optimiz...

On 4/3/2014 12:58 AM, Nick Kledzik wrote: > On Apr 2, 2014, at 11:02 AM, Shankar Easwaran wrote: > >> On 4/2/2014 12:23 PM, Nick Kledzik wrote: >>> On Apr 1, 2014, at 9:19 PM, Shankar Easwaran wrote: >>> >>>> The API's that would be in LinkingContext would be :- >>>> >>>> * virtual bool canDemangle() = 0; // Does the

...aggregates. That requires aggregate accesses to be described >> the same way we describe scalar accesses. >> >> To provide some background on importance of this matter, SROA and >> passing flattened parameters/returning values in clang together >> produce 75% of all undecorated loads and 90% if all undecorated >> stores on the LLVM code base under -O1. >> >> >> On 31/10/17 10:44, Ivan Kosarev wrote: >>> In short, the problem with !tbaa.struct is that in most cases it >>> cannot be converted to !tbaa. For transformations like SRO...

> It also has the problem that there's nothing preventing a > pass like GVN from merging a !fpmath-decorated operation with an > undecorated operation, and nothing requiring it to strip > the !fpmath tag when it does so. (This is a general problem > with LLVM metadata semantics.) Can it? My impression from the last discussion on alias analysis is that a pass can drop metadata it doesn't know, but it cannot ignore it, so GVN w...

...ssname function so as to be able to invoke "ncol" directly and transparently. However, it is not the case. The only alternative I can think about is to create decorated versions of ncol, nrow, etc. to avoid naming conflicts. But I would still prefer my package users to be able to use the undecorated function names. Do I have a chance? Best regards, Carlos J. Gil Bellosta http://www.datanalytics.com

On Thu, Dec 16, 2010 at 06:16:25PM -0000, Anton Lokhmotov wrote: > Mike Gist wrote: > > You could also consider placing all kernel functions in a 'kernel' > > section, or adding a function attribute for kernels. > Unlike in Clang, function attribute bit-fields in LLVM are pretty crowded > (only couple of bits are unused?). Besides, we do not want to represent >

...to accesses to scalars, that is, load and store instructions. Currently, we decorate instructions that initialize and copy aggregates with !tbaa.struct tags that generally cannot be transformed to !tbaa tags. For this reason every time we scalarize an aggregate, we leave resulting loads and stores undecorated, meaning optimization of such instructions cannot benefit from TBAA. Furthermore, our analysis indicates that the only place where !tbaa.struct tags may potentially impact code generation is simplification of memcpy() and memmove() calls, see SimplifyMemTransfer() in InstCombineCalls.cpp. Ironical...

...ing else to support this, but it won't be metadata. Why are you trying to preserve "kernel"-ness into the LLVM IR? What semantics does it have? What does __kernel actually mean to the optimizers and code generator? Could you just make __kernel mean "externally visible" and undecorated functions be "linkonce_odr"? If that's not enough, could you swing it around and maintain single named metadata node with a list of functions that are marked __kernel? Nick I do have a concern though with the semantics of the inliner when it > needs to inline a function with meta...

However we record the fact that a function is a kernel, the mechanism should handle the case of a kernel calling another kernel. Recall that a kernel called by another kernel behaves more like a regular function. For example it doesn't have workspace iteration automatically applied to it; rather it just adopts the work item of the caller. About using a calling convention to mark a function

...s to Kenny Levinsen for their contributions on polishing rootful mode. Kenny Levinsen (4): xwayland: Commit after acknowledging configure xwayland: Make xwl_window_libdecor_resize reusable xwayland: Apply root toplevel configure dimensions xwayland: Default geometry for undecorated rootful Olivier Fourdan (1): Bump version to 23.2.0 git tag: xwayland-23.2.0 https://xorg.freedesktop.org/archive/individual/xserver/xwayland-23.2.0.tar.xz SHA256: 7f33ec2a34de6e66ae1b7e44872c3a2146192872c719b9acf192814edbabd4c5 xwayland-23.2.0.tar.xz SHA512: 3b490839026da4d34136d5005039...

...on is undocumented). I believe there is also something similar in the AMD Stream IL. As for the other attributes mentioned above, I don't know off-hand, but I believe there are PTX directives for at least some of them. > Could you just make __kernel mean "externally visible" and undecorated > functions be "linkonce_odr"? I think the semantics of undecorated functions is closer to "internal" than "linkonce_odr" here (kernel programs shouldn't be able to provide a definition for functions in another module, such as a runtime library module). > I...

...ways this can fail. I don't understand how it can not be safe: if the metadata is dropped then the optimizers have to be more strict, thus it is safe. > It also has the problem that there's nothing preventing a > pass like GVN from merging a !fpmath-decorated operation with an > undecorated operation, and nothing requiring it to strip > the !fpmath tag when it does so. (This is a general problem > with LLVM metadata semantics.) This is true, what do you suggest as a solution? > The current definition of !fpmath does not appear to require > operations to return the same r...

...ng Ubuntu's Unity mode: http://ubuntuforums.org/showthread.php?t=1742354. I work for VMware and for our Unity mode (which has the unfortunate name as Ubuntu's new Unity mode), where we show individual guest Virtual Machine windows in the Linux host environment as individual windows, we use undecorated windows, similar to how Wine shows Windows applications in X without having to be inside the full Windows desktop container. The problem I'm trying to figure out a solution for is that when our user maximizes the guest window and then unmaximizes it in Ubuntu 11.04's default Unity desktop e...

On Tue, 17 Apr 2012 08:38:18 -0400 Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > It also has the problem that there's nothing preventing a > > pass like GVN from merging a !fpmath-decorated operation with an > > undecorated operation, and nothing requiring it to strip > > the !fpmath tag when it does so. (This is a general problem > > with LLVM metadata semantics.) > > Can it? My impression from the last discussion on alias analysis is > that a pass can drop metadata it doesn't know, but it c...

...s when removing decoration from a window. Correctly terminate move action if it was initiated by decoration button press and the button binding was not set to <some modifier>+Button1. Fixed annotate erase invocation and termination. Don't try to get button positions for undecorated windows. Always use the current window decoration extents instead of the custom decoration extents, which may not be currently used (e.g. if the window was excluded from decorations). Fixed annotate erase mode. Revert "Fixed annotate erase mode." Fix erase mode....

Hello all: I have searched through the help files and I have been unsuccessful in solving this problem. I am trying to create a small wrapper function that will go around a call to a plot function and create a windows metafile in the directory and also write the name of the file to a text file. The purpose is to efficiently bring a large number of plots into powerpoint. I am using