similar to: suboptimal type isomorphy handling involving opaque structs

Displaying 20 results from an estimated 300 matches similar to: "suboptimal type isomorphy handling involving opaque structs"

2014 May 22
2
[LLVMdev] RFC: Indexing of structs vs arrays in getelementpointer
On May 22, 2014, at 3:51 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Thu, May 22, 2014 at 4:42 PM, Louis Gerbarg <lgg at apple.com> wrote: > The problem that the above transform is technically illegal because “When indexing into a (optionally packed) structure, only i32 integer constants are allowed (when using a vector of indices they must all be the same
2014 May 23
2
[LLVMdev] RFC: Indexing of structs vs arrays in getelementpointer
----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Louis Gerbarg" <lgg at apple.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, May 22, 2014 7:09:49 PM > Subject: Re: [LLVMdev] RFC: Indexing of structs vs arrays in getelementpointer > > > > >
2014 May 22
4
[LLVMdev] RFC: Indexing of structs vs arrays in getelementpointer
Recently I posted a patch to migrate certain GEPs between basic blocks in cases where doing so would improve the ability of instcombine to merge into more complicated addressing mode (r209049 and r209065). After some build to failures it was rolled back. I now have a patch that no longer causes the regressions I was seeing, but it also no longer can optimize the case I was trying to optimize. As
2019 Aug 20
2
missing simplification in ScalarEvolution?
Hi, I have this small test case- %struct1 = type { i32, i32 } @glob_const = internal constant [4 x %struct1] [%struct1 { i32 4, i32 5 }, %struct1 { i32 8, i32 9 }, %struct1 { i32 16, i32 0 }, %struct1 { i32 32, i32 10 }], align 16 define void @foo() { entry: br label %loop loop: ; preds = %loop, %entry %iv = phi %struct1* [ getelementptr
2019 Aug 21
2
missing simplification in ScalarEvolution?
Thanks for the suggestion but datalayout info did not solve the problem! -Pankaj -----Original Message----- From: Philip Reames <listmail at philipreames.com> Sent: Tuesday, August 20, 2019 5:26 PM To: Chawla, Pankaj <pankaj.chawla at intel.com>; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] missing simplification in ScalarEvolution? Try adding a datalayout with pointer size
2019 Aug 26
2
missing simplification in ScalarEvolution?
Hi Sanjoy, Thanks for the reply! Your approach sounds good to me! I think 1) is legal as address wraparound in unsigned range doesn't make sense given a positive offset, but I am not sure. I think umax will not be added if we can prove the predicate as known. I am not sure whether umax will get simplified if we add nuw to the expressions. -Pankaj -----Original Message----- From: Sanjoy
2008 Jun 06
1
calling a C function with a struct
I am trying to call a precompiled C function that uses a struct as one of it's arguments. I could write a wrapper function in C, but I was hoping there is some way to pack fields into an array of type raw that could be passed directly to the function. Here is some more detail. The C struct is simple, but has mixed types: struct STRUCT1 { long type; long nx; double
2012 Dec 30
0
[LLVMdev] Cannot interchange "literal" and "identified" structs
Justin, http://llvm.org/docs/LangRef.html#structure-type "Identified types can be recursive, can be opaqued, and are never uniqued." Do you think it would be less descriptive? "Identified type, aka named llvm::StructType, is never uniqued against other identified types nor literal types, aka unnamed StructType(s)." ? See also;
2012 Dec 30
2
[LLVMdev] Cannot interchange "literal" and "identified" structs
With primitive types, I can interchange literal usage and type aliases in IR: %mytype = type i32 define void @foo(%mytype* %ptr) { %t1 = load *%mytype** %ptr store i32 *%t1*, *i32** %ptr ret void } But for structs, I cannot: %mytype = type { i32, i32 } define void @foo(%mytype* %ptr) { %t1 = load *%mytype** %ptr store* { i32, i32 }* %t1, *{ i32, i32 }** %ptr ret void }
2019 Apr 20
0
Re: [iGVT-g] GVT-g - suboptimal user experience
Could you elaborate a bit more about the first two features? On UEFI VMs support (Windows guest), do you mean enabling Windows VM display on UEFI? Thanks. > -----Original Message----- > From: iGVT-g [mailto:igvt-g-bounces@lists.01.org] On Behalf Of Alex Ivanov > Sent: Friday, April 19, 2019 2:51 AM > To: libvirt-users@redhat.com; igvt-g@lists.01.org; virt-tools-list@redhat.com >
2019 May 09
0
Re: [iGVT-g] GVT-g - suboptimal user experience
> -----Original Message----- > From: Gerd Hoffmann [mailto:gerd@kraxel.org] > Sent: Thursday, May 9, 2019 3:28 PM > To: Alex Ivanov <gnidorah@ya.ru> > Cc: Yuan, Hang <hang.yuan@intel.com>; libvirt-users@redhat.com; igvt- > g@lists.01.org; virt-tools-list@redhat.com > Subject: Re: [iGVT-g] GVT-g - suboptimal user experience > > Hi, > > > 1. Its
2019 May 09
0
Re: [iGVT-g] GVT-g - suboptimal user experience
Hi, > 1. Its about local display / dmabuf feature. Currently user needs to > use virt-viewer tool. But virt-manager already incorporates graphical > console. It would be nice if it could support accelerated gvt-g local > display. virt-manager and virt-viewer essentially run the same code spice client code: both are using the spice-gtk widget. So, if that isn't working
2019 May 19
1
Re: [iGVT-g] GVT-g - suboptimal user experience
So it looks like this solution is currently not very user friendly. Perhaps Intel could get Red Hat help to make first-class support of gvt feature in virt-manager? 09.05.2019, 10:28, "Gerd Hoffmann" <gerd@kraxel.org>: >   Hi, > >>  1. Its about local display / dmabuf feature. Currently user needs to >>  use virt-viewer tool. But virt-manager already incorporates
2019 Apr 18
2
GVT-g - suboptimal user experience
Hi. In the current state of gvt-g the user experience is suboptimal. So my question is what are the ETAs for following features: 1. Accelerated virt-manager console using gvt-g device 2. Custom resolutions or dynamic resolution 3. UEFI VMs support (Windows guest) Thanks.
2014 Nov 28
2
[LLVMdev] ScalarEvolution: Suboptimal handling of globals
Hi, For the program below, where "incr" and "Arr" are globals ================================= int incr; float Arr[1000]; int foo () {   float x = 0;   int newInc = incr+1;   for (int i = 0; i < 1000; i++) {     for (int j = 0; j < 1000; j += incr) {         x += (Arr[i] + Arr[j]);     }   }   return x; } ================================= The SCEV expression computed
2019 Aug 08
2
Suboptimal code generated by clang+llc in quite a common scenario (?)
Hi Tim and Alex Thanks for your replies. So just to make it clear for me: does this imply that there’s indeed no way on the current version to tell the compiler or Clang to optimize this? Thanks, Joan > On 8 Aug 2019, at 18:30, Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, 8 Aug 2019 at 17:08, Alex Brachet-Mialot via llvm-dev > <llvm-dev at
2008 Oct 22
2
suboptimal lp solutions
Hi list, I want to find the total maximum resources I can spend given a set allocation proportion and some simple budget constraints. However, I get suboptimal results via lp and friends (i.e. lpSolve and simplex in the linprog and boot) . For example: library(lpSolve) proportions = c( 0.46, 0.28, 0.26) constraints = c( 352, 75, 171) lp(objective.in = proportions, const.mat =
2019 May 08
3
Re: [iGVT-g] GVT-g - suboptimal user experience
Hello. All features are about usability and simple user experience. 1. Its about local display / dmabuf feature. Currently user needs to use virt-viewer tool. But virt-manager already incorporates graphical console. It would be nice if it could support accelerated gvt-g local display. Preferably with minimum performance overhead. Also virt-manager should allow to use mdev videocard alone,
2019 Aug 08
3
Suboptimal code generated by clang+llc in quite a common scenario (?)
This might not be the workaround you want because it is only available in C, but you can use restrict to allow such optimizations. https://godbolt.org/z/2gQ26f Alex On Thu, Aug 8, 2019 at 11:50 AM Michael Kruse via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > char* scscx is an universal pointer and may point to anything, > including itself. That is, scscx might
2016 May 10
14
[Bug 95334] New: GM107 with 2560x1440 display on HDMI selects suboptimal resolution 1920x1080
https://bugs.freedesktop.org/show_bug.cgi?id=95334 Bug ID: 95334 Summary: GM107 with 2560x1440 display on HDMI selects suboptimal resolution 1920x1080 Product: xorg Version: 7.7 (2012.06) Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium