Run Closure with No Optimizations? #3204

Closed
zz85 opened this Issue Feb 20, 2015 · 9 comments

Projects

None yet

2 participants

@zz85
zz85 commented Feb 20, 2015

while trying to hunt down this problem for glsl-optimizer emscripten port, I tried compiling using emcc flags

-O0 --closure 1

however, this would yield the warning

disabling closure because debug info was requested

So I added the parameter -g0 to ensure that debug information is removed, but doing so still fails.

Looking into the source of emcc and I found that

if opt_level == 0: debug_level = max(3, debug_level)

results no optimzations enforcing a debug level of at least 3, ignoring the -g flag.

Is this intentional?

@kripken
Owner
kripken commented Feb 20, 2015

I suppose if a debug level was explicitly specified, we should not modify that. I'm curious though, why do you want closure without optimizations? It would likely build extremely slowly on large projects (closure scales nonlinearly with number of variables, with we reduce ourselves before calling closure in -O2 and above).

@zz85
zz85 commented Feb 20, 2015

i see. i started looking only at this option because every time i started compiling https://github.com/zz85/glsl-optimizer with optimizations, the webpage hangs. would you have a clue to why that happens?

@kripken
Owner
kripken commented Feb 24, 2015

There definitely shouldn't be any change - except for a speedup - when optimizing. Build with assertions etc. , might find something http://kripken.github.io/emscripten-site/docs/porting/Debugging.html?#compiler-settings

@zz85
zz85 commented Feb 24, 2015

thanks for that advice, i'll try that out!

@zz85
zz85 commented Feb 27, 2015

@kripken using emcc -O1 -g -s TOTAL_MEMORY=33554432 -s ASSERTIONS=1 -s SAFE_HEAP=1 -s DEMANGLE_SUPPORT=1 I get no compiler warnings, but during runtime I get segmentation fault storing 4 bytes to address 0 error.

image

@zz85
zz85 commented Feb 27, 2015

maybe to give a more details, i run my compilation in 2 steps (first build a bitcode library, before linking with --embind support as embind compilation fails building with the library). Below is the -O0 version, which compiles and runs fine, but replacing -O0 with -O1, that would result in a runtime error.

emcc -Isrc -Isrc/mesa -Iinclude src/mesa/program/prog_hash_table.c src/mesa/program/symbol_table.c src/mesa/main/imports.c src/glsl/glcpp/glcpp-lex.c src/glsl/glcpp/glcpp-parse.c src/glsl/glcpp/pp.c src/util/hash_table.c src/util/ralloc.c src/glsl/ast_array_index.cpp src/glsl/ast_expr.cpp src/glsl/ast_function.cpp src/glsl/ast_to_hir.cpp src/glsl/ast_type.cpp src/glsl/builtin_functions.cpp src/glsl/builtin_types.cpp src/glsl/builtin_variables.cpp src/glsl/glsl_lexer.cpp src/glsl/glsl_optimizer.cpp src/glsl/glsl_parser.cpp src/glsl/glsl_parser_extras.cpp src/glsl/glsl_symbol_table.cpp src/glsl/glsl_types.cpp src/glsl/hir_field_selection.cpp src/glsl/ir.cpp src/glsl/ir_basic_block.cpp src/glsl/ir_builder.cpp src/glsl/ir_clone.cpp src/glsl/ir_constant_expression.cpp src/glsl/ir_equals.cpp src/glsl/ir_expression_flattening.cpp src/glsl/ir_function.cpp src/glsl/ir_function_can_inline.cpp src/glsl/ir_function_detect_recursion.cpp src/glsl/ir_hierarchical_visitor.cpp src/glsl/ir_hv_accept.cpp src/glsl/ir_import_prototypes.cpp src/glsl/ir_print_glsl_visitor.cpp src/glsl/ir_print_metal_visitor.cpp src/glsl/ir_print_visitor.cpp src/glsl/ir_rvalue_visitor.cpp src/glsl/ir_stats.cpp src/glsl/ir_unused_structs.cpp src/glsl/ir_validate.cpp src/glsl/ir_variable_refcount.cpp src/glsl/link_atomics.cpp src/glsl/link_functions.cpp src/glsl/link_interface_blocks.cpp src/glsl/link_uniform_block_active_visitor.cpp src/glsl/link_uniform_blocks.cpp src/glsl/link_uniform_initializers.cpp src/glsl/link_uniforms.cpp src/glsl/link_varyings.cpp src/glsl/linker.cpp src/glsl/loop_analysis.cpp src/glsl/loop_controls.cpp src/glsl/loop_unroll.cpp src/glsl/lower_clip_distance.cpp src/glsl/lower_discard.cpp src/glsl/lower_discard_flow.cpp src/glsl/lower_if_to_cond_assign.cpp src/glsl/lower_instructions.cpp src/glsl/lower_jumps.cpp src/glsl/lower_mat_op_to_vec.cpp src/glsl/lower_named_interface_blocks.cpp src/glsl/lower_noise.cpp src/glsl/lower_offset_array.cpp src/glsl/lower_output_reads.cpp src/glsl/lower_packed_varyings.cpp src/glsl/lower_packing_builtins.cpp src/glsl/lower_ubo_reference.cpp src/glsl/lower_variable_index_to_cond_assign.cpp src/glsl/lower_vec_index_to_cond_assign.cpp src/glsl/lower_vec_index_to_swizzle.cpp src/glsl/lower_vector.cpp src/glsl/lower_vector_insert.cpp src/glsl/lower_vertex_id.cpp src/glsl/opt_algebraic.cpp src/glsl/opt_array_splitting.cpp src/glsl/opt_constant_folding.cpp src/glsl/opt_constant_propagation.cpp src/glsl/opt_constant_variable.cpp src/glsl/opt_copy_propagation.cpp src/glsl/opt_copy_propagation_elements.cpp src/glsl/opt_cse.cpp src/glsl/opt_dead_builtin_variables.cpp src/glsl/opt_dead_builtin_varyings.cpp src/glsl/opt_dead_code.cpp src/glsl/opt_dead_code_local.cpp src/glsl/opt_dead_functions.cpp src/glsl/opt_flatten_nested_if_blocks.cpp src/glsl/opt_flip_matrices.cpp src/glsl/opt_function_inlining.cpp src/glsl/opt_if_simplification.cpp src/glsl/opt_minmax.cpp src/glsl/opt_noop_swizzle.cpp src/glsl/opt_rebalance_tree.cpp src/glsl/opt_redundant_jumps.cpp src/glsl/opt_structure_splitting.cpp src/glsl/opt_swizzle_swizzle.cpp src/glsl/opt_tree_grafting.cpp src/glsl/opt_vector_splitting.cpp src/glsl/opt_vectorize.cpp src/glsl/s_expression.cpp src/glsl/strtod.c src/glsl/standalone_scaffolding.cpp -DHAVE___BUILTIN_FFS=0 -o glslopt.bc -O0 -s TOTAL_MEMORY=33554432  -s ASSERTIONS=1  -s SAFE_HEAP=1  -g

emcc glslopt.bc -Isrc/glsl src/emscripten/EmMain.cpp  -o glsl-optimizer.js -DUSE_EMBINDS=1 --bind -s EXPORTED_FUNCTIONS="['_optimize_glsl']" -O0 -s TOTAL_MEMORY=33554432  -s ASSERTIONS=1  -s SAFE_HEAP=1  -g
@kripken
Owner
kripken commented Mar 9, 2015

It's possible the app has undefined behavior, and -O1 takes advantage of it.

If you can't figure it out, please try to make as standalone a testcase as you can, and I can take a look.

@zz85
zz85 commented Jun 27, 2015

I decided to upgrade to emscripten 1.30.0 today and give this another shot, however I am still unable to find the source of the problem. I'm guessing it could be a runtime behaviour of the program, since it's running a parser, depending on different inputs it could get different unexpected behaviour.

As for the content I'm using, I seem to be able to trace it down to a loop in the parser. The details of where the error gets thrown is in this gist, allow with the debugged output and the original source function.

https://gist.github.com/zz85/faa2f220080651723369#file-asm-js-L54

I'm not sure if this is a problem worth pursuing, but it'd be great if you get other ideas.

@zz85
zz85 commented Jul 22, 2015

Turns out the cause of this issue is not emscripten but rather gcc/clang compiler optimizations was ignoring side modifications of linked lists in glsl-optimizer. See https://bugs.freedesktop.org/show_bug.cgi?id=91320

Closing this as it is resolved in zz85/glsl-optimizer#1 (comment) Thanks!

@zz85 zz85 closed this Jul 22, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment