joverbey / oaccrefac Goto Github PK

View Code? Open in Web Editor NEW

1.0 7.0 1.0 24.83 MB

Java 74.68% C++ 0.15% C 21.08% Shell 0.28% Makefile 0.13% HTML 3.49% CSS 0.06% JavaScript 0.02% Fortran 0.11%

oaccrefac's Introduction

oaccrefac

Setting Up Eclipse Neon with the Source Code

Download and install Eclipse Neon. Get the "Eclipse IDE for Eclipse Committers" package or the Eclipse SDK.
In Eclipse, click Help > Install New Software. From the "Work with" dropdown, select "Neon." After the list of features loads:
- Expand "Programming Languages," and check "C/C++ Development Tools SDK."
- Expand "Programming Languages," and check "C/C++ UPC (Unified Parallel C) Support."
- Expand "General Purpose Tools," and check "Parallel Tools Platform."
- Expand "General Purpose Tools," and check "PTP Parallel Language Development Tools UPC Support."
- Then click Next, Next, Accept, Finish.
Click Window > Perspective > Other, select Git, and click OK. This will open the Git perspective.
In the Git Repositories view, click "Clone a Git repository," select "Clone URI," and click Next. Enter the URI: [email protected]:joverbey/oaccrefac.git then click Next. Check "Import all existing Eclipse projects after clone finishes," and click Finish.
Click Window > Preferences. Expand "Plug-in Development" and select "API Baselines." Click "Add Baseline." Make sure "An existing Eclipse installation directory" is checked, and click Next. In the "Name" box, enter "Installation." Click Refresh, then click Finish. Then, click OK to close the Preferences dialog, and when prompted, choose "Yes" to perform a full build.

oaccrefac's People

Contributors

Stargazers

Watchers

Forkers

mendezmariano

oaccrefac's Issues

Dependence testing for loop tiling

In the loop tiling refactoring, there's an issue regarding loop tiling dependence analysis. There's no way to access the changed AST mid-rewrite. Therefore, there's the issue of how to do interchange dependence analysis on loop tiling after the strip mining change because the actual strip mined header is inaccessible.

Strip Mining bugs

Allows index to be modified in loop body
Does not allow if or switch statements
Does not allow break within an inner loop
Does not allow sizeof operator
Does not allow inner while loop
Accepts any numerical type for the index (even double), but converts them to int
Allows loop conditional to be <=, but converts to <

Constant Propagation improvements needed

(1) CP should be able to continue in the presence of return statements

(2) If a local variable is not aliased (its address is not taken), then a function call cannot change its value.

For example, in EPCC Level 1 gemm(), the value of n is constant (512), but CP cannot detect this.

Strip mine doesn't check for counted loops

No check is done in the check, and the alteration assumes that it is counted in some ForLoopInquisitor calls

Losing a comment in a Distribute Refactoring

Example:

  /* loop60outer */int n =100;
  for (int i = 0; i < n; i++){
      /* loop60inner */
    for (int j = 0; j < n; j++){
      int a = 100;
      /* loop60inner2 */
      for (int k = 0; k < n; k++){
        int a = 100;
      }
    }

Loop60inner Distribute Refactored:

  /* loop60outer */int n =100;
  for (int i = 0; i < n; i++){
      /* loop60inner */
    for (int j = 0; j < n; j++) {
        int a = 100;
    }
    for (int j = 0; j < n; j++) {
        for (int k = 0; k < n; k++) {
            int a = 100;
        }
    }
  }

////Losing /* loop60inner2 */ during Distribute Refactoring of loop60inner

OpenACC node removal leaves useless whitespace

For #pragma acc data copyin(b, i) copyout(a), when removing b from the copyin clause using IASTListNode#remove(int index) (specifically, I think the list node is an ASTSeparatedListNode), we get #pragma acc data copyin( i) as the result. The whitespace before the i is legal, but shouldn't be there.

our parser vs. PGI compiler data construct discrepancy

Our parser will not parse a data construct with no clauses, i.e.,

#pragma acc data
{
    ...
}

but the PGI compiler seems to compile it fine, so our parser should probably allow a clause list of length 0 or more.

IntroduceDataConstruct is ok with separating an if statement from its else

If the selection includes an if statement but not the following else statement, it goes ahead and surrounds the if but not the else with a new data construct, leaving an orphaned else.

Dependence Analysis for Introduce Kernels Loop and Introduce Parallel Loop incorrect

The following code:

int main() {
    int a, b, c, d;
    #pragma acc parallel loop
    for (int i = 0; i < 100; i++) {
        a = 5;
        b = 6;
        c = 7;
        d = 8;
    }
}

Gives the error message

ERROR: This loop cannot be parallelized because it carries a dependence.
Context: 
code: none
Data: null

when attempting to introduce a parallel loop, but there are definitely no dependencies.

Dependence analysis should not require perfectly nested loops

From level1.c (EPCC Level 1) line 223 (twomm):

  /* E := A*B */
  for (i = 0; i < n; i++) { /*<<<<< 220, 1, 227, 4, loop7outer*/
    for (j = 0; j < n; j++){ /*<<<<< 221, 1, 226, 6, loop7inner*/
      E[i*n+j] = 0;
      for (k = 0; k < n; k++){ /*<<<<< 223, 1, 225, 8, loop7inner2*/
        E[i*n+j] += A[i*n+k] * B[k*n+j];
      }
    }
  }

We can't handle the full loop nest because it is not perfectly nested ("unsupported statement"). We should be able to analyze a simple, obvious matrix multiplication...

ASTUtil.getStatementsIfCompound is never used, but its functionality is

A few refactorings (not sure which) use the functionality but should be refactored to use this method instead

MergeDataConstructs adds a pointless newline after pragma

This:

#pragma acc parallel loop
for (int i = 0; i < 3; i++) {
    a[i] = b[0];
    b[i] = c[1];
    c[i] = d[2];
    d[i] = a[0];
}

becomes this:

#pragma acc parallel loop copyin(a,b,c) copy(d)

for (int i = 0; i < 3; i++) {
    a[i] = b[0];
    b[i] = c[1];
    c[i] = d[2];
    d[i] = a[0];
}

when merging constructs that surround the parallel region. I've seen it happen on a couple of different tests, but I haven't tried to see if it happens when no data clauses are added to the parallel loop pragma.

Dependence analysis test failures

I'm getting NPEs in several of the dependence analysis unit tests. Screenshot:

Intro Data Construct should check for unsupported control flow statements

Applied to the following code, Intro Data Construct adds #pragma acc data create(a,done) which is incorrect. Goto statements should probably not be supported. We should also test for other control flow statements (break, continue) if we're not already.

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    int a[10][10];

        #pragma acc parallel loop
    for (int i = 0; i < 10; i++) {
        for (int j = 0; j < 10; j++) {
            a[i][j] = i * 10 + j;
            goto done;
        }
    }

done:
    return EXIT_SUCCESS;
}

Refactoring names should be verb phrases

Following conventions, the names of refactorings should be verb phrases. E.g.:

Strip Mine Loop
Tile Loop Nest
Parallelize Loop (OpenACC)
Distribute Loop
Fuse Loops
Interchange Loops
Unroll Loop

These names should be reflected in all UI elements, documentation, and class names, for consistency.

Dependence analysis fails to gives results as expected

Dependences:

On the loop in the picture, I believe there should be ANTI 12 -> 12 [<, =, =], OUTPUT 12 ->12 [=, =, =], and OUTPUT 9 -> 9 [=, =, =]. The result we get includes all possible ANTI 12 ->12 [<, x, x] and several OUTPUT 12 -> 12 [=, x, x], so the result is effectively correct for those two. However, it is missing the output dependence on the write to E in between the loops, which is incorrect.

Analysis on this matrix multiplication loop directly copied from EPCC level 1:

is currently showing no dependences at all, which is certainly incorrect - there should at least some OUTPUT [=, =, =] on writes to E and something between the read of E on line 12 and the writes.

(I'm creating this issue as a branch off of #6 since its discussion evolved into something other than what the issue was originally for. May also be related to #4)

IntroduceDataConstruct doesn't care if it causes scoping issues

I.e., if you surround a variable declaration, it moves it to an inner scope, so you have to surround all of its uses as well. Right now, there is no check for this. ExpandDataConstruct has checks for this, so that code might could be reused here.

NPE in Intro Parallel/Kernels radio button listeners

After the Introduct OpenACC Loop refactoring is activated, clicking on the "Regular" and "Kernels" radio buttons in the dialog box causes an NPE:

java.lang.NullPointerException
    at org.eclipse.ptp.pldt.openacc.internal.ui.ButtonSelectionListener.widgetSelected(ButtonSelectionListener.java:49)
    at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248)
    at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
    at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4230)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1491)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1514)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1499)
    at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1299)
    at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4072)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3698)
    at org.eclipse.jface.window.Window.runEventLoop(Window.java:827)
    at org.eclipse.jface.window.Window.open(Window.java:803)
    at org.eclipse.ltk.ui.refactoring.RefactoringWizardOpenOperation$1.run(RefactoringWizardOpenOperation.java:187)
    at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
    at org.eclipse.ltk.ui.refactoring.RefactoringWizardOpenOperation.run(RefactoringWizardOpenOperation.java:202)
    at org.eclipse.ltk.ui.refactoring.RefactoringWizardOpenOperation.run(RefactoringWizardOpenOperation.java:122)
    at org.eclipse.cdt.internal.ui.refactoring.RefactoringStarter.activate(RefactoringStarter.java:33)
    at org.eclipse.cdt.internal.ui.refactoring.RefactoringRunner.run(RefactoringRunner.java:43)
    at org.eclipse.ptp.pldt.openacc.internal.ui.actions.refactoring.RefactoringActionDelegate$1.run(RefactoringActionDelegate.java:56)
    at org.eclipse.ptp.pldt.openacc.internal.ui.actions.refactoring.RefactoringActionDelegate.run(RefactoringActionDelegate.java:58)
    at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:247)
    at org.eclipse.ui.internal.WWinPluginAction.runWithEvent(WWinPluginAction.java:228)
    at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:595)
    at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:511)
    at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:420)
    at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
    at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4230)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1491)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1514)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1499)
    at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1299)
    at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4072)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3698)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1127)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1018)
    at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156)
    at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:654)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
    at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:598)
    at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
    at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:139)
    at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1515)
    at org.eclipse.equinox.launcher.Main.main(Main.java:1488)

Refactorings replace preprocessing indirection

As it is, when a refactoring creates new nodes from a factory based off of nodes (or copies of nodes) from the original AST, the preprocessor directives that originally represented the identifiers are replaced by their expanded version.

In example, if the original source was this:

define n 10

int i = 0;
for (int i = 0; i < n; i++) {
i = n;
}

suppose some refactoring was done, the output could look like this...

define n 10

int i = 0;
for (int i = 0; i < 10; i++) {
i = 10;
}

Because the ASTRewrite from CDT is limited and does not handle preprocessors, we need some sort of mapping algorithm within our refactorings that can reapply the preprocessor directives to their unexpanded versions.

UI Test Inconsistent

UI test are throwing inconsistent pass/failure results with no changes made to code.

Constant Propagation Can't Evaluate Upper Bound

The unrolling test for llloops "Kernel 1 -- hydro fragment" fails because the upperBound of the loop never gets set by constant propagation. The place it should be set is in UnrollLoopCheck.java in the constructor. The loop which fails is in llloops.c between lines 1129 and 1132.

for ( k=0 ; k<n ; k++ ) /*<<<<< 1129, 1, 1132, 10, Kernel1 */
{
    x[k] = q + y[k]*( r*z[k+10] + t*z[k+11] );
}

Bugs in Introduce Parallel/Kernels Loop

If there is already an acc parallel or acc parallel loop directive in an enclosing scope, Introduce Parallel Loop should only introduce acc loop (not acc parallel loop)
An acc parallel loop cannot be nested under an acc kernels or acc kernels loop, and an acc kernels loop cannot be nested under an acc parallel or acc parallel loop
A loop cannot be parallelized there is a break statement that breaks out of that loop

Suspicious new line on IntroDefaultNone

IntroDefaultNone adds a new line after the introduce pragma statement for

#pragma acc parallel
    {
        for (int i = 0; i < 10; i++) {
            //b += a;
        }
    }

Intro Default None should be removed

It is still present in the Refactor menu. Not sure if @acalvert or @aggrand wants to take care of this...

SourceAlteration: incorrect offset with multiple sequential alterations

There is no issue when a single alteration method (replace, remove, or insert) is called, but when multiple of those methods are called by a single SourceAlteration instance, sometimes the internal tracking fields don't point to the correct places in either the file or in the internal StringBuilder. It makes weird stuff (or no stuff at all) happen when the text change actually goes through. I'm not more specifically sure what sequences of calls/inputs causes the problem, but the issue arises when calling:

this.remove(getPragma());
...
this.replace(getStatement(), newConstruct);

if the node returned by getPragma() is entirely lexically before the node returned by getStatement().

ReachingDefinitions incorrect result on array definitions

For example,

for(int i = 0; i < 10; i++) {
    a[i] = b[2]; //#1
    b[i] = a[2]; //#2
}

#2 is should be reached by definitions of a preceding the loop, as well as by #1, but reaching definitions as it is treats an array as a single "atomic" unit.

This was by design for simplicity originally, but when inferring copyins (imagine adding a parallel loop construct around the loop), a really must be copied in, since an existing value from it is used on the device. Thus, the reaching definitions should probably give that result.

ASTPatternUtil.isDefinition() needs cleanup

The whole method is basically a sequence of special case checks on the form of the AST and could be improved in terms of readability and debuggability by redoing it to use the pattern matching from AbstractDependenceAnalysis or from ASTPatternUtil or something. It has no known bugs, but the nature of it being a bunch of nigh-unreadable special cases suggests that there may be unhandled corner cases.

Dependence analysis should handle linearized arrays

From EPCC Level 1 syrk (level1.c line 682):

  for (i = 0; i < n; i++){/*<<<<< 682, 1, 686, 4, loop35outer*/
    for (j = 0; j < n; j++){/*<<<<< 683, 1, 685, 6, loop35inner*/
      C[i*n+j] *= beta;
    }
  }

The dependence analysis is reporting flow, anti-, and output dependences on the body statement, with direction vector [*, *].

This is really a linearized 2-D array with width n, so we would like for the dependence analysis to determine that the writes to C are independent. The value of n is constant:

int n = 1024;

ExpandDataConstruct expands around declarations but keeps declared variables in existing copy sets

This shouldn't happen

Unsupported statement checks should be consistent

There are at least three different ways to determine whether a function/loop contains a statement that cannot be analyzed/refactored:

ForLoopCheck#containsUnsupportedOp
ForStatementInquisitor#getFirstUnsupportedStmt
Perform a dependence analysis and see if it fails

We should make sure the refactorings have a consistent notion of what is (un)supported and a consistent way of checking for it.

ASTMatcher doesn't consider types in for loop initiializer declarations

int main() {

    int N = 100;
    double a[N];
    for (double i = 0; i < N; i++) { /*<<<<< 5,1,8,3,2,pass*/
        a[1] = i;
    }

}

This is strip mined without question

Problems in ForStatementInquisitor

There are a couple of problems in ForStatementInquisitor:

private static boolean counted;

This shouldn't be static. This means there's only one counted variable shared among all the Inquisitors, so an inquisitor for one loop could end up getting the value of counted for a completely different loop.

Also, at line 139:

} catch(IllegalStateException e){
            e.getMessage();
            System.exit(4);
        }

Three problems with this:

Generally speaking, IllegalStateException should never be caught. It indicates a programming error and should never occur in production code.
e.getMessage() returns a string but doesn't do anything else, so that line has no effect.
System.exit() should only be executed in the CLI code. The Inquisitor will also be accessed from Eclipse. This will shut down the entire JVM, terminating Eclipse. In general, classes in the Core package can't make any assumptions as to whether they're running in the CLI, Eclipse, the Web demo, or some future user interface. They should throw exceptions, and the calling package (CLI, Eclipse, etc.) should decide how to respond to those exceptions.

Dependence analysis confused on constant scalar

In this piece of code, we get dependences as expected:

but here, we get all stars:

The difference is that one declared n as an int and the other #defines it as a constant.

The problem seems to occur when parsing the subscript as a linear expression. In the latter example, that parsing fails, so the subscript expression on the VariableAccess comes back null. VariableAccess#isScalarAccess (or whatever it's called) simply returns whether that field is null, so all accesses to E (and probably A and B as well) come back as scalars. Is constant propagation needed?

Implication: This likely means that any truly non-linear subscript expression will come back as a scalar. This may be desired behavior, but I'm not actually sure.

IntroDataConstruct won't surround an if statement appropriately

When selecting all of

if (n) {
    for (j = 1; j < n; j++)
        a[j][i] = b[j][i] + 1;
}

it yields

if (n)
#pragma acc data
    {   {
            for (j = 1; j < n; j++)
            a[j][i] = b[j][i] + 1;
        }}

Cannot interchange perfectly nested loops with loop inside innermost body

    for(int i = 0; i < 10; i++) {
        for(int j = 0; j < 10; j++) {
            int x;
            for(int k = 0; k < 10; k++) {

            }
        }
    }

You should be able interchange the i and j loop, but instead you get an error saying, "Only perfectly nested loops can be interchanged." The loops interchange just fine when commenting out the k loop.

NPE in Strip Mine test 14

Strip mine test 14 is failing for me with this NPE:

java.lang.NullPointerException
    at org.eclipse.ptp.pldt.openacc.core.transformations.AbstractTileLoopsAlteration.doChange(AbstractTileLoopsAlteration.java:43)
    at org.eclipse.ptp.pldt.openacc.core.transformations.SourceAlteration.change(SourceAlteration.java:94)
    at org.eclipse.ptp.pldt.openacc.internal.ui.refactorings.StripMineLoopRefactoring.refactor(StripMineLoopRefactoring.java:51)
    at org.eclipse.ptp.pldt.openacc.internal.ui.refactorings.ForLoopRefactoring.collectModifications(ForLoopRefactoring.java:98)
    at org.eclipse.cdt.internal.ui.refactoring.CRefactoring.checkFinalConditions(CRefactoring.java:130)
    at org.eclipse.ptp.pldt.internal.tests.refactorings.RefactoringTest.test(RefactoringTest.java:285)
    at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at org.junit.runners.Suite.runChild(Suite.java:128)
    at org.junit.runners.Suite.runChild(Suite.java:27)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
    at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62)
    at org.eclipse.pde.internal.junit.runtime.PlatformUITestHarness$1.run(PlatformUITestHarness.java:47)
    at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
    at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
    at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4024)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3700)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1127)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1018)
    at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156)
    at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:654)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
    at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:598)
    at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
    at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:139)
    at org.eclipse.pde.internal.junit.runtime.NonUIThreadTestApplication.runApp(NonUIThreadTestApplication.java:54)
    at org.eclipse.pde.internal.junit.runtime.UITestApplication.runApp(UITestApplication.java:47)
    at org.eclipse.pde.internal.junit.runtime.NonUIThreadTestApplication.start(NonUIThreadTestApplication.java:48)
    at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1515)
    at org.eclipse.equinox.launcher.Main.main(Main.java:1488)

Dependence analysis should handle if-statements

Several of the EPCC level 1 benchmarks (loops 13 and 19, for example) contain if-statements. We should handle these, initially by just treating them as one large statement with no internal control flow (to avoid handling control dependences).

Distribute Loops should not distribute declarations

Distribute Loops should not work on the following loop, but it does (creating code that will not compile). I believe, in general, it should refuse to distribute loops where a declaration statement (like int k below) is one of the statements that would be distributed.

        for (int j = 0; j < 10; j++) {
            int k = i * 10 + j;
            a[i][j] = k;
        }

Loop Cutting should have some sort dependence analysis check

Theoretically, if you cut

for(int i = 0; i < 9; i++) {
    a[i] = a[i] - 3;
}

with a cut factor of 3, there should be a dependence issue, since (for example) a[6] will be written before a[3] in the cut loop, but after a[3] in the original loop.
I guess dependence distance should have something to do with the analysis.

Dependence analysis should handle some function calls

The dependence analysis should handle function calls.

Math functions like sin, cos, log, fabs can be whitelisted as "known" pure functions
For other function calls, we can assume the the values of any local variables whose address is taken might change

EPCC uses rand() and fabs()

IntroDefaultNone IllegalStateException

IntroDefaultNone check throws an IllegalStateException if refactoring a pragma that is not allowed to have a default none clause - should just be a fatal error

Loops are said to carry dependence that shouldn't

In hello.c file used for testing:

#include <stdio.h>
#include <stdlib.h>

#define N 10

int main(void) {
int a[N];

for (int j = 0; j < 5; j++)
    for (int i = 0; i < N; i++)
        a[i] = i;

for (int i = 1; i < N; i++) {
    int j = a[i];
    a[i] = j + 1;
}

return EXIT_SUCCESS;
}

all loops are said to carry dependencies even though they shouldn't

SourceAlteration formats out whitespace replacement

When replacing a chunk of text with whitespace, the formatter alters it. I.e., if replacing text with a single newline character, it gets formatted to an empty string and never gets inserted.

CASTUnaryExpression cast to IASTBinaryExpression exception

On loop41inner in epcc-level1 there is a CASTUnaryExpression cast to IASTBinaryExpression exception after having run the loopcutting refactoring with parameter cut of 2. (j < n) is the Expression in question I believe. Attached is the error thrown after running in the CMDtool.
cast exception.txt

Scalars always create a star dependence

The DependenceAnalysis explicitly fills the direction vectors for scalars with stars. This causes errors when performing refactorings on them.

Unnecessary InferCopyin inference

#pragma acc data
    {
#pragma acc parallel loop
        for (i = 0; i < 10; i++)
            a = i;
    }
#pragma acc data
    {
#pragma acc parallel loop
        for (i = 0; i < 10; i++) {
            a = i;
        }
    }

When merging the data constructs, it infers that i should be copied in, but it shouldn't be (should probably be created instead).

ExpandDataConstruct doesn't handle comments

Unit tests right now assume that comments are not handled; that should be changed as well once this functionality is added.

Errors in FourierMotzkinEliminator#eliminateForIntegerSolutions

This loop nest is essentially a strip-mined version of "for i = 0 to 30 a[i] = a[i-1]" but the dependence tester is returning no dependences.

for (int j = 0; j < 10; j++)
    for (int k = 0; k < 3; k++)
        a[3*j+k] = a[3*j+k-1];

The DependenceAnalysis class is creating a DirectionHierarchyTester dht with

lowerBounds = [0, 0]
upperBounds = [9, 2]
writeCoefficients = [[0, 3, 1]]
readCoefficients = [[-1, 3, 1]]
no other variables

and then dht.getPossibleDependenceDirections() is returning an empty set.

@blockhead54 would you mind looking into this? Thanks.

Pragma being moved with loop interchange

Should the pragma be moving like this with loopinterchange?

FusionDependenceAnalysis passes unit tests when passing in the loops to be fused instead of the statements in their bodies

The API expects the body statements, but somehow it seems to work fine when giving the two for loops. As the API goes, this means both loops passed in are expected to be in the body of the resulting loop, which leads to weird dependences in theory that don't seem to come up in the unit tests.

joverbey / oaccrefac Goto Github PK

oaccrefac's Introduction

oaccrefac

Setting Up Eclipse Neon with the Source Code

oaccrefac's People

Contributors

Stargazers

Watchers

Forkers

oaccrefac's Issues

define n 10

define n 10

Recommend Projects

Recommend Topics

Recommend Org