similar to: [LLVMdev] Support for Windows Phone 8.1

Damanjit Singh wrote: > Hi guys, > > Would really appreciate any help here. > > Thanks, > Daman > > From: Damanjit Singh <dsingh at adobe.com <mailto:dsingh at adobe.com>> > Date: Friday, 6 June 2014 12:57 pm > To: "llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu>" > <llvmdev at cs.uiuc.edu <mailto:llvmdev at

Thanks Saleem, Nick. I will try with the latest code and share the results. Though, just curious if I need to really use clang to generate the object file and the current steps won't work? I ask because using .c file was only an illustration. For my project the IR is not generated from .c files or clang. Thanks, Daman Sent from my phone On 08-Jun-2014, at 11:00 am, "Saleem

Thanks a lot Saleem, The issue is fixed and a simple app works fine now. -Daman On 08/06/14 12:57 pm, "Nick Lewycky" <nicholas at mxc.ca> wrote: >Damanjit Singh wrote: >> Thanks Saleem, Nick. >> >> I will try with the latest code and share the results. >> >> Though, just curious if I need to really use clang to generate the >> object file

Hi Saleem, Though a simple app works great I am facing few issues trying to link a slightly complex object file, generated via LLVM, with some libs generated via Visual Studio - 1. Seems IMAGE_SCN_MEM_16BIT is only written for the the first header in the COFF file, thus functions in other headers (if you are using function sections) don’t work. I was able to workaround this by forcing this entry

On Wed, Jun 18, 2014 at 10:25 AM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Wed, Jun 18, 2014 at 9:09 AM, Damanjit Singh <dsingh at adobe.com> wrote: > >> Hi Saleem, >> >> Though a simple app works great I am facing few issues trying to link a >> slightly complex object file, generated via LLVM, with some libs generated >> via

I am not using llvm tools, but sources and directly calling into relevant LLVM classes and methods. Thanks, Daman On 23/06/14 4:11 pm, "Amara Emerson" <amara.emerson at gmail.com> wrote: >Hi Damanjit, > >I assume you're trying to use the tools like llvm-mc, in which case >you can use the -mattr=+vfpv3 flag to enable it. This applies to other >subtarget

How can I ensure use of VFP3 via LLVM target options? I am currently using thumbv7-windows-msvc as the target triple and default set of llvm::TargetOptions. Thanks, Daman -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140623/bdf36cce/attachment.html>

Hi, I am trying to understand the semantics of Instructions in llvm. Are the following instructions semantically same? * %add2 = add nsw i32 %add, %add1 %add3 = add i32 %add, %add1* Based on my understanding from the Language Reference Manual, I think they are different. But then why is the *gvn* pass detecting *%add3* as redundant and deleting it? Your views are appreciated. Rekha

On Wed, Jul 23, 2014 at 4:06 PM, Rekha R <rekharamapai at nitc.ac.in> wrote: > Ok. Got it. > > If *add nsw* overflows, this results in undefined value. > But then *add* on same arguments results in well-defined value. > > Hence treating first one as redundant based on the second is acceptable. > But vice versa is not. > If they are in different code paths, sure.

Hello, I am trying to figure out, what vrp propagation does in llvm. I tried this program: #include <stdio.h> int main() { int s = 0; int j = 0; for (int i = 0; i < 100; i++) { j = j+i+1; s+=j; } return (s+j); } And got this under optimized version ( I don't want everything to be eliminated) define i32 @main()

> Then why does the Release Note say > " the operation is guaranteed to not overflow". It means that the person who wrote the IR has guaranteed that there's no overflow (by some means) so LLVM can assume it during optimisation. This guarantee might come from doing explicit checks before executing the add/sub; or perhaps from performing the operation after a sext so that the

IMHO; On undefined behaviour we can do whatever we want. If the "add nsw" overflows this would lead to undefined behaviour. Therefore we can assume that "add", with the same arguments will not overflow. On Wed, Jul 23, 2014 at 3:32 PM, Tim Northover <t.p.northover at gmail.com> wrote: > On 23 July 2014 06:25, Rekha R <rekharamapai at nitc.ac.in> wrote: >

Hi Michael, >Interesting approach but how do you handle more complex offsets, e.g., when the pointer is part of an aggregate? Only one offset does not seem enough to handle generic cases. Yes, correct, this a little bit changed example is not working. #include <x86intrin.h> __m256d vsht_d4_fold(const double* ptr, unsigned long long i) { __m256d foo = (__m256d){ ptr[i], ptr[i+1],

Hi Nadav, Thanks for the quick reply !! Ok, so as of now we are lacking capability to handle flat large reductions. I did go through function vectorizeChainsInBlock() (line number 2862). In this function, we try to vectorize if we have phi nodes in the IR (several if's check for phi nodes) i.e we try to construct tree that starts at chains. Any pointers on how to join multiple trees? I

Maybe it would illustrative to give an IR example of the case I'm interested in. Consider define void @"julia_transform_bvn_derivs_hessian!"(double* %data, double* %data2, double *%data3, double *%out) { %element11 = getelementptr inbounds double, double* %data, i32 1 %load10 = load double, double* %data %load11 = load double, double* %element11 %element21 =

Hi, I am trying to understand LLVM vectorization implementation and was looking into both loop and SLP vectorization. test case 1: *int foo(int *a) {int sum = 0,i;for(i=0; i<16; i++) sum += a[i];return sum;}* This code is vectorized by loop vectorizer where we calculate scalar loop cost as 4 and vector loop cost as 2. Since vector loop cost is less and above reduction is legal to

Hi Arnold, Thanks for your reply. I tried test case as suggested by you. *void foo(int *a, int *sum) {*sum = a[0]+a[1]+a[2]+a[3]+a[4]+a[5]+a[6]+a[7]+a[8]+a[9]+a[10]+a[11]+a[12]+a[13]+a[14]+a[15];}* so that it has a 'store' in its IR. *IR before vectorization :*target datalayout = "e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128" target triple =

On Mon, Aug 7, 2017 at 2:14 AM, Anastasiya Ruzhanskaya via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I am trying to print it like this (maybe here is smth wrong?) > > > LazyValueInfo &LV = getAnalysis<LazyValueInfoWrapperPass>().getLVI(); > DominatorTree &DT = > getAnalysis<DominatorTreeWrapperPass>().getDomTree(); > LV.printLVI(F,

Hi Suyog, Thanks for looking at this. This has recently got itself onto my TODO list too. > I am not sure how much all this will improve the code quality for horizontal reduction > (donno how frequently such pattern of horizontal reduction from same array occurs in real world/SPECS). Actually the main loop of 470.lbm can be SLP vectorized like this. We have three parts to it: A fully

Hi Michael, >I have a case where InstCombine removes a store and your approach would be >valuable for me if the entire access to an aggregate could be restored. Yes, no problem and we could add the aggregate pointer to this new intrinsic and in my particular case I should ignore it, but I am looking now at "speculation_marker" metadata and I am still not sure how to implement it