search for: 5f5f5f

...face="sans-serif">Thanks,</font><br><br><font size=2 face="sans-serif">--Doru</font><br><br><br><font size=2 face="sans-serif"><br></font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From: </font><font size=1 face="sans-serif">"Doerfert, Johannes" <jdoerfert@anl.gov></font><br><font size=1 color=#5f5f5f face="sans-serif">To: </font><font size=1 face="sans...

Thanks Florian. Tim you said: > Some cases can be undone by rematerialization, but not all, and it can involve a lot of effort which increases compile time. Do you have examples of cases where rematerialization is not possible? We are interested in learning about any previous attempts at trying to address the issue in RA. Have you tried it? Bardia Mahjour Compiler Optimizations IBM Toronto

On Thu, Mar 9, 2017 at 9:57 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 03/01/2017 05:30 PM, Daniel Berlin via llvm-dev wrote: > > So, https://bugs.llvm.org/show_bug.cgi?id=32056 is an example showing our > current TBAA tree for union generation is definitely irretrievably broken. > I'll be honest here. I'm pretty sure your proposal doesn't go far enough.

Hi, Thanks for your help! I've checked the sources that you mentioned. Currently, I think that I would need to implement a FunctionToLoopNestPassAdaptor which is essentially the same as the FunctionToLoopPassAdaptor but operates only on LI.getTopLevelLoops(). We might also need a LNPMUpdater (LoopNestPassManagerUpdater) which disallows adding inner-loops back into the pipeline, and

Where we are ------------ Currently, when we generate OpenMP target offloading code for GPUs, we use sufficient syntactic criteria to decide between two execution modes: 1) SPMD -- All target threads (in an OpenMP team) run all the code. 2) "Guarded" -- The master thread (of an OpenMP team) runs the user code. If an OpenMP distribute region is encountered,