January 2011 - Ad-dev - mailman3.cels.anl.gov

[openAD] #200: introduce scope per CFG node
by OpenAD 18 Nov '14

18 Nov '14

#200: introduce scope per CFG node -------------------------+-------------------------------------------------- Reporter: utke | Owner: snarayan Type: enhancement | Status: new Priority: major | Milestone: Component: xaif | Keywords: -------------------------+-------------------------------------------------- for C++, with default scope being the same scope as the top level cfg scope for C/fortran -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/200> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 5

[openAD] #220: COMMON block symbol reference ambiguity in whirl
by OpenAD 22 Feb '13

22 Feb '13

#220: COMMON block symbol reference ambiguity in whirl --------------------------+------------------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: new Priority: major | Milestone: Component: OpenADFortTk | Keywords: --------------------------+------------------------------------------------- for the following situation: subroutine foo () common /g/ v ... call bar() end subroutine subroutine bar() common /g/ v/ ... end subroutine the global whirl symbol table has 2 entries for 'v' (and also 'g'), one for each PU in which v is used. The association is done via the base ST of 'v' first to its corresponding 'g' and then that one's corresponding base symbol is either 'bar' or 'foo'. Normally the uses of the different incarnations do not overlap. However, the side effect analysis reports cumulative side effects in "foo" including sideeffects of 'bar' on bar's version of 'v' such that in foo now implicitly separate references occur (for checkpointing code) of both 'v' instance and that in turn leads to a duplication of the common block declaration in the unparser because there is no logic that can turn bar::v into the equivalent foo::v to avoid the bogus reference. This will have to be fixed either in OpenADFortTk or in whirl2f. -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/220> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 5

[openAD] #245: DATA stmt: allow (object , value) pairs to not be separated by comma
by OpenAD 18 Apr '11

18 Apr '11

#245: DATA stmt: allow (object , value) pairs to not be separated by comma ------------------------------+--------------------------------------------- Reporter: utke | Owner: utke Type: enhancement | Status: new Priority: major | Milestone: Component: SourceProcessing | Keywords: ------------------------------+--------------------------------------------- for a complete implementation of the syntax spec (R532) which says the comma between the pairs is optional -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/245> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 4

[openAD] #233: parser fails on labeled do
by OpenAD 05 Apr '11

05 Apr '11

#233: parser fails on labeled do ------------------------------+--------------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: new Priority: major | Milestone: Component: SourceProcessing | Keywords: ------------------------------+--------------------------------------------- test case is PrePost/TestSources/UnStruct_controlflow_loop4.free.f90 -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/233> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 1

[openAD] #213: postProcess.py needs to add value selector (and do nothing else) for original function definitions that have been turned into subroutines
by OpenAD 31 Mar '11

31 Mar '11

#213: postProcess.py needs to add value selector (and do nothing else) for original function definitions that have been turned into subroutines ------------------------------+--------------------------------------------- Reporter: lyonsam | Owner: utke Type: defect | Status: new Priority: major | Milestone: scale1 Component: SourceProcessing | Keywords: ------------------------------+--------------------------------------------- The issue is this: you know how we have postprocess and transformfile? I have a situation where there's a function in centrm (in centrm/psget_I.f90) that gets subroutinized by the preprocessor, so that both the function and the new subroutine go through the tool. As is usually the case when we do this, the subroutine will have active statements whereas the function will not (because we've replaced all the function calls that we've seen with subroutine calls, so the function isn't used in an active context). So far so good. In this case, though, the function uses a module variable that happens to be active, like {{{ passive1 = active*passive2 }}} where we would need {{{ passive1 = active%v*passive2 }}} So here's what we need: for function units, the postprocessor should do exactly what transformfile does (like adding the %v whenever an active variable is referenced), and none of the stuff that the postprocessor does on non-function units. -- Ticket URL: <http://trac.mcs.anl.gov/projects/openAD/ticket/213> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 2

[openAD] #238: allow Brackets [] used for array constructor
by OpenAD 23 Mar '11

23 Mar '11

#238: allow Brackets [] used for array constructor ------------------------------+--------------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: new Priority: major | Milestone: Component: SourceProcessing | Keywords: ------------------------------+--------------------------------------------- -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/238> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 2

[openAD] #262: function2subroutine - incorrect hoisting of variables
by OpenAD 21 Mar '11

21 Mar '11

#262: function2subroutine - incorrect hoisting of variables ------------------------------+--------------------------------------------- Reporter: utke | Owner: utke Type: defect | Status: new Priority: major | Milestone: AD for SAS Component: SourceProcessing | Keywords: ------------------------------+--------------------------------------------- -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/262> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 7

[openAD] #254: fix up initialization flag for postprocessing so it doesn't require reverse mode
by OpenAD 21 Mar '11

21 Mar '11

#254: fix up initialization flag for postprocessing so it doesn't require reverse mode ---------------------------------+------------------------------------------ Reporter: utke | Owner: hcm Type: defect | Status: new Priority: major | Milestone: Component: multiple components | Keywords: ---------------------------------+------------------------------------------ The fix committed as http://mercurial.mcs.anl.gov/ad/RegressionOpenAD/rev/c7231724e2a4 works but I don't agree with what it does because the postprocessor options we accept shouldn't be restricted to adjoint and I don't understand why initialization would have to be tied to reverse mode. IOW - I think rather than changing the test script I would instead permit the post processor to do the initialization bits. A subsequent question that was still to be verified was if there could be cases where initialization of local variables was also needed in forward mode. so http://mercurial.mcs.anl.gov/ad/RegressionOpenAD/rev/c7231724e2a4 should be undone and replaced by a fix in SourceProcessing -- Ticket URL: <https://trac.mcs.anl.gov/projects/openAD/ticket/254> OpenAD <http://www.mcs.anl.gov/openad> Bug tracking for OpenAD components

1 2

[ADIC] #49: Cast Expressions
by ADIC 26 Jan '11

26 Jan '11

#49: Cast Expressions ------------------------------+--------------------------------------------- Reporter: snarayan | Owner: snarayan Type: defect | Status: new Priority: minor | Milestone: Component: Canonicalization | Version: 2.0 Keywords: | ------------------------------+--------------------------------------------- There seems to be no nice way to handle a type cast expression: void mini2(double *y, double *x) { int i; double j; y[i] = x[(int)(j)]; } The XAIF created is: <xaif:AssignmentLHS> <xaif:SymbolReference annotation="28301536" scope_id="7" symbol_id="y" vertex_id="1"></xaif:SymbolReference> <xaif:ArrayElementReference vertex_id="1"> <xaif:IndexTriplet> <xaif:Index> <xaif:VariableReference vertex_id="4"> <xaif:SymbolReference annotation="28301632" scope_id="8" symbol_id="i" vertex_id="1"></xaif:SymbolReference> </xaif:VariableReference> <xaif:Intrinsic name="sub_scal_scal" vertex_id="6"></xaif:Intrinsic> <xaif:Constant type="integer" value="1" vertex_id="5"></xaif:Constant> <xaif:ExpressionEdge edge_id="1" position="1" source="4" target="6"></xaif:ExpressionEdge> <xaif:ExpressionEdge edge_id="2" position="2" source="5" target="6"></xaif:ExpressionEdge> </xaif:Index> </xaif:IndexTriplet> </xaif:ArrayElementReference> <xaif:VariableReferenceEdge edge_id="1" source="1" target="1"></xaif:VariableReferenceEdge> </xaif:AssignmentLHS> <xaif:AssignmentRHS> <xaif:VariableReference vertex_id="7"> <xaif:SymbolReference annotation="28301584" scope_id="7" symbol_id="x" vertex_id="1"></xaif:SymbolReference> <xaif:ArrayElementReference vertex_id="8"> <xaif:IndexTriplet> <xaif:Index> <xaif:VariableReference vertex_id="11"> <xaif:SymbolReference annotation="34735904" scope_id="8" symbol_id="SgCastExp_34735904" vertex_id="1"></xaif:SymbolReference> </xaif:VariableReference> </xaif:Index> </xaif:IndexTriplet> </xaif:ArrayElementReference> <xaif:VariableReferenceEdge edge_id="1" source="1" target="8"></xaif:VariableReferenceEdge> </xaif:VariableReference> </xaif:AssignmentRHS> </xaif:Assignment> With the derivative code: void ad_mini2(DERIV_TYPE *y,DERIV_TYPE *x) { DERIV_TYPE ad_TempVarprp_1; zero_deriv(&ad_TempVarprp_1); /* int i; double j; y[i - 1] =(x[(int )j]); */ int ad_i; DERIV_TYPE ad_j; DERIV_val(y[ad_i - 1]) = DERIV_val(x[(int )ad_j]); ADIC_SetDeriv(DERIV_TYPE_ref(x[(int )ad_j]),DERIV_TYPE_ref(ad_TempVarprp_1)); ADIC_SetDeriv(DERIV_TYPE_ref(ad_TempVarprp_1),DERIV_TYPE_ref(y[ad_i - 1])); } If type casting cannot be handled by XAIFBooster, then XAIFVistor should ensure that (int )ad_j becomes (int )(ad_j.val()) in the derivative code. This example is unlikely to be a problem very soon. -- Ticket URL: <http://trac.mcs.anl.gov/projects/ADIC/ticket/49> ADIC <http://trac.mcs.anl.gov/projects/ADIC> ADIC: Automatic Differentiation for C and C++

1 1

[ADIC] #48: Enhancements for the Runtime Library
by ADIC 19 Jan '11

19 Jan '11

#48: Enhancements for the Runtime Library ------------------------------+--------------------------------------------- Reporter: snarayan | Owner: snarayan Type: enhancement | Status: new Priority: major | Milestone: Component: Canonicalization | Version: Keywords: | ------------------------------+--------------------------------------------- 1. Separate the Sparse and Dense runtime libraries from the main ADIC library.The user should also get a local copy of the runtime library which should also solve the issue of setting the ADIC_GRADVEC_LENGTH in two places. 2. Make the sparse and dense runtime interfaces the same. Therefore, the differentiated code will be created once, but can be linked against the sparse or dense libraries on demand. 3. All routines in the runtime libraries should be changed to macos as far as possible. 4. Dynamically create both the sparse and dense Sax/Saxpy macros. 5. Instead of an STL::set and and STL:: list of sets to maintain non-zero Jacobian, think of other ways. 6. All DERIV_TYPE objects should have their grad array zeroed out, temporaries should have their values zeroed out. This step maybe unneeded if XAIFBooster always sets the values of temporaries before use. 7. Create a way for the user to know that the generated code can overrun stack space, and that temporaries and existing variables should be dynamically allocated. 8. Create a way to dynamically allocate temporaries and existing variables. -- Ticket URL: <http://trac.mcs.anl.gov/projects/ADIC/ticket/48> ADIC <http://trac.mcs.anl.gov/projects/ADIC> ADIC: Automatic Differentiation for C and C++

1 1