llvm dev - Jan 2013 - [LLVMdev] Loads not hoisted out of the loop

On 1/18/2013 11:11 AM, Dimitri Tcaciuc wrote:
>
> Right, I see. Is there any other way to solve this? As the last resort,
> I was considering silently transforming each Array argument into
> separate data and metadata arguments, but that would certainly add other
> complications I'd rather avoid.
Depends on what information you have available.  If all you have is the 
LLVM IR, then the only universal solution that I can think of is 
interprocedural analysis, where you would track the pointer values, and 
potentially determine that they never point to overlapping memory areas.

> I was also think ing a hypothetical LLVM-based Fortran compiler would be
> the model to aim for, where they have dimension-aware arrays that never
> alias (AFAIK?). I wonder how one would solve that problem there.
I think the proper way would be to use metadata after all, and have some 
alias analysis that could understand it.

-Krzysztof


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

----- Original Message -----
> From: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
> To: "Dimitri Tcaciuc" <dtcaciuc at gmail.com>
> Cc: llvmdev at cs.uiuc.edu
> Sent: Friday, January 18, 2013 11:22:26 AM
> Subject: Re: [LLVMdev] Loads not hoisted out of the loop
> 
> On 1/18/2013 11:11 AM, Dimitri Tcaciuc wrote:
> >
> > Right, I see. Is there any other way to solve this? As the last
> > resort,
> > I was considering silently transforming each Array argument into
> > separate data and metadata arguments, but that would certainly add
> > other
> > complications I'd rather avoid.
> 
> Depends on what information you have available.  If all you have is
> the
> LLVM IR, then the only universal solution that I can think of is
> interprocedural analysis, where you would track the pointer values,
> and
> potentially determine that they never point to overlapping memory
> areas.
> 
> 
> > I was also think ing a hypothetical LLVM-based Fortran compiler
> > would be
> > the model to aim for, where they have dimension-aware arrays that
> > never
> > alias (AFAIK?). I wonder how one would solve that problem there.
> 
> I think the proper way would be to use metadata after all, and have
> some
> alias analysis that could understand it.
I agree. FWIW, I'm currently working on making the LLVM-based Fortran
compiler non-hypothetical, and so for several reasons, I'd like to have a
solution to this. If we can't think of anything better, we could always fall
back to the N^2 metadata solution (explicit mark as no-alias all pairs that
don't alias), but I'd rather we come up with something else.

 -Hal
> 
> -Krzysztof
> 
> 
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory

On 1/18/2013 11:34 AM, Hal Finkel wrote:
>
> I agree. FWIW, I'm currently working on making the LLVM-based Fortran
compiler non-hypothetical, and so for several reasons, I'd like to have a
solution to this. If we can't think of anything better, we could always fall
back to the N^2 metadata solution (explicit mark as no-alias all pairs that
don't alias), but I'd rather we come up with something else.
How about having Fortran-specific metadata, and a Fortran-specific alias 
analysis?  The metadata could indicate how the properties of the 
Fortran-frontend-generated types relate to the types that the IR code 
uses to load/store data.  For example:

f90_array_type = type { i32 size, double* data };
metadata = "attributes of f90_array_type, like restrict, should be 
applied to the member pointer 'data'"

Is this something you've considered?

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation